FAQ

Good question! It’s rare that you would need to update your WordPress multisite’s domain (it usually happens when moving between the live site and a local or staging environment), but it’s very troublesome to do, and it involves manually updating many different entries in the multisite’s database. That can be tricky even for advanced users, and downright scary for somebody who isn’t well-acquainted with WordPress multisite databases.

This site makes things easier by generating a single SQL query that you can run in the database to automatically make all the updates for you, so that you shouldn’t have to edit database field values manually at all.

Only your main domain (what you enter in the “replace this domain” field) in these specific tables and columns:

wp_options: the rows named “siteurl” and “home”
wp_site
wp_sitemeta: the row named “siteurl”
wp_blogs: all entries in the “domains” column that have the domain
wp_#_options: the “siteurl” and “home” rows. (“#” equals each of your subsite’s ID numbers.)

There are a few of places to find this. The most certain way is to look inside your wp-config.php file, which you’ll find in the root folder of your WordPress install.

You should see a line in that file (usually about halfway down) that begins with $table_prefix. The text in quotes following that is what you’re looking for. In the example below (and generally by default), this is wp_.

$table_prefix = 'wp_';

You can also view your database directly through phpMyAdmin or your host's database manager. Your database prefix will be the text which is shared by all of the WordPress tables.

Managed hosts may also have a place to view your database prefix from the site’s dashboard. (The database prefix of Flywheel sites, for example, can be found in the Advanced tab of the site’s Flywheel dashboard.)

This is usually the same as the total number of subsites you have in your WordPress multisite network. So you can do one of two things here. Either:

• Access your WordPress multisite’s database and find the wp_blogs table. (If your database prefix is something other than wp_, substitute your database prefix. You can locate the table easily once you’re in the database by using your browser’s find function for the word “blogs”.)
  
  Click into that table to view its data, and you should see that the first column is blog_id. You just want to find the highest number in that column;

OR:

• Just put any number that you know is higher than the total number of subsites you’ve ever had. That may make the query very long (and it may therefore take a while to run), but it should do the trick.

Yes! Both subdomain (subsite.mysite.com) and subdirectory (mysite.com/subsite) domain configurations can be effectively updated with this tool.

If you're not sure, odds are you don't. It's extremely uncommon for a database prefix to not end in an underscore, and multisites don't use the blog ID number “1” by default.

First things first: be sure you have a backup!

You’ll need to access your site’s database manager. This might be phpMyAdmin, or your host may have a different database manager.

Regardless, once you access the database, you should see a tab that says “SQL,” or possibly “Query.”

If you click that, you should see a large text field to paste your command into.

Every host is different, so while this general set of instructions should cover most cases, you may need to reach out to your host to find out how to run SQL commands and whether that’s possible.

If you’re on Flywheel, you’ll find your database in the Advanced tab of the site’s Flywheel dashboard. Click the “Manage” button (it will appear when you hover over the database card) then click the SQL tab in the next screen to find your SQL command input field.

With most search-and-replace commands, you’d probably want to include the protocol; that helps insure the command doesn’t replace things it shouldn’t. But the SQL command you’ll get from this tool is specifically written to only target the specific places where your multisite’s domain is found in the database, so there’s absolute minimal worry of the command replacing things it shouldn’t.

Some of those places do include the “http://” portion of the domain, but some do not. So in order to make the search as comprehensive and targeted as possible, it’s important to leave “http://” off of the domain so that the command will hit every instance of the domain that it needs to.

See the “What specific parts of my multisite database are being updated when I run this command?” section above and check those locations to make sure the change was made.

If not, your search term may have been inaccurate, or wasn’t targeted enough to get your main domain.

But if so, the most likely explanation is that there are references to your old domain hard-coded into the site, or in places in the database that aren’t targeted.

For example, if you (or your site’s developer) added an image link somewhere in WordPress or in a template file where the site’s old domain was explicitly typed out, that code may not be replaceable via standard search-and-replace methods, and may instead need to be manually updated.

It could also mean that a plugin or theme has added extra database tables which aren’t included in the standard WordPress install, and which are therefore not included in this site’s search.

It’s also worth double-checking that the proper database prefix was entered, that the blog_id number entered was high enough, and that the correct domain was entered for the search, with no “http://” or “/” before or after it.

No. This tool is specifically designed for updating your WordPress multisite network’s domain only. That’s all it’s meant for.

For general search-and-replace purposes, there are other plugins and pre-built SQL commands readily available.

No. Or rather: it will work to the extent possible, but it can’t have any impact on the mapped domains. Those will need to be updated manually, since the SQL command can’t possibly update them on its own.

Potentially, yes, but it’s not recommended and may not work as intended.

If used on a single site, only one part of the SQL command will succeed: the part that searches and replaces the option_value column of the wp_options table.

If all of the links in your site are relative, this should be enough to effectively change the domain of a single WordPress site. However, it may have unintended side effects as well (it did in my testing), so I’d strongly recommend seeking out other options intended for standard, single WordPress sites. This tool just isn’t built for it.

As long as most of the individual commands are running successfully, it’s ok that some of them fail. This will likely happen if there are skipped blog_id numbers in the wp_blogs table.

For example, if the blog_id numbers of your subsites are 1, 2 and 4, the query that searches and replaces the subsite with the blog_id of 3 will fail, since that subsite doesn’t exist. That’s ok, though, and it shouldn’t stop the rest of the command from running successfully.

If none of the command is working, double-check your database table prefix and the domain you’re searching, and confirm that you haven’t already updated the domain.

It’s extremely rare that a WordPress site would have a database prefix which did not end in an underscore, but on the off-chance this happens to you, there’s an advanced option to allow it.

There’s ALWAYS risk in running SQL commands, so please do so with extreme caution. It is possible that running a bad SQL command could break your site entirely and/or make it inaccessible, although this tool is designed to absolutely minimize the chances of that happening and help you to run exactly the right command.

Even so, you should always back up your database before running any SQL commands in case something goes wrong.

WordPress multisite databases are very complex, and it’s impossible to predict all the variances that may occur either within their configuration or that may have been made by plugins and themes. So again, always have a database backup ready to go just in case.

Yes.* If you just need to change your multisite’s domain temporarily and then change it back again later (such as to stage a site before going live), just use this tool again when you’re ready to switch back, and reverse the two domain fields.

*That said: be careful. There isn’t any real “undo” in SQL. If the “new domain” field already exists in the database, you may get some weird results and catch extra things when going back.

You may use this site for anything you like, but it’s only designed to search and replace the domain of standard subdomain or subsite WordPress multisite networks.

Whatever you do, however, by using this site you accept the responsibility for the risk involved. As explained above, while I’ve gone to great lengths to make this tool as easy to use and as foolproof as possible based on standard multisite network installations, WordPress multisite network databases are very complex, and there’s no way to know or predict how your multisite database is configured.

Always get a database backup before running any SQL commands and you should be good. But regardless, you use this tool at your own risk.