Many times I have been tasked to build two websites for a business. As a developer it is my responsibility to advise how these two websites should interact, or if they should interact at all. This can be very difficult for the developer, and can be very expensive for the client.
In this post I will share from my past experiences – good and bad – to try to help you make the right decision.
The question is: If you are building two websites, which should you use?
- Two separate WordPress websites
- One multisite with two sub-sites
- One website connected to two domains
Table of contents:
- A brief comparison of multisite options
- Chapter 1: What if we use one install for two domains?
- Chapter 2: Should we use a multisite instead?
- Chapter 3: Should we use two separate websites?
- In conclusion
- Side note: What about merging two sites into a multisite?
A brief comparison of multisite options
Here is a rough and subjective estimate of the cost compared to building just one website:
- Two separate installs: 200% cost
- Multisite for two websites: 300% cost
- One website supporting two domains: 900%+ cost
Two separate installs is best when…
- Both sites use a different theme
- Both sites use different pages, menus, plugins, etc
- Very few users need to have a login on both sites
- Do NOT use this option if you foresee users needing to have significant data in sync with each other
A multisite is best when…
- You and your agency have prior experience with multisites already
- Theme can be the same, or different
- Plugins can be the same, or different
- Pages, menus, and forms can be completely separate
- Many users need to have a login on both sites
- Users need to have data shared between sites (excluding username, email, and passwords)
- Do NOT use this option just to make it easier for administrators to switch between sites
Use a single install on two domains if:
- Both sites use the same theme, pages, menus, plugins, forms
- Both sites use 100% the same users, data, and settings
- Do NOT use this option to make it easier for administrators
- Do NOT use this option when there are only some or even many similarities between the sites
- Do NOT use this option if you foresee some changes to site A but not to site B
- IMPORTANT: There are very few, if any plugins designed to pull this off effectively. I’ve tried many of them. In the end I used parts from other plugins to build one that worked. I highly doubt you will find a turnkey plugin to pull this off.
Chapter 1: What if we use one install for two domains?
That’s simpler than building a multisite, right? WRONG. Don’t do it.
I have only one very niche exception where I have successfully implemented this sort of system. It was very expensive. There were dozens, perhaps hundreds of unfreeable issues that came up.
If I were to do this again it would still take just as long. Any estimate I give you for such a system will be well below the end cost. No matter how detailed my documentation and checklists are, steps will be missed. The host might have certain rules that interfere with the setup. There are so many things that can go wrong.
Here are some examples to give you an idea of the sort of problems you will face:
Example 1:
Suppose you are logged in on Site A. You navigate to Site B, knowing they are exactly the same server, database, IP address, and even theme. So you switch over, logged in and ready to go! Nope, wrong.
To remedy such a situation I built a Single Sign On plugin which polls the other site to see if you are logged in, run some security checks, handshake with some encrypted keys. Got it all working. I was very pleased with myself. And not even a day later, problems started coming in:
- What happens if you sign out on Site A? You stay signed in on Site B.
- What happens if you switch user? The other site is the previous user.
- What happens if you switch back? Who even knows.
Example 2:
Say you are in the same boat as the project I had built. The site is exactly the same. Same header, same footer, same theme. The only difference really is that some colors change, the site title is different, and the occasional logo is swapped out.
A week later, the client requests the header have a new link for Site B. Suddenly you have to duplicate a menu or template, or hide a link conditionally based on the domain.
Then they want a form to have a new field for Site A. A different payment method on Site B.
Not even a month later your theme is split into dozens of if statements and your menus are prefixed with Site A and Site B so you can tell the difference. Maintenance takes longer, problems are more difficult to identify, and it’s only going to compound itself over time.
No other developers understand your setup. Hopefully you’ve written excellent documentation. Hopefully every fix or workaround you implement is properly documented.
And after all of that, do you think another developer is going to read through the entire documentation to fully grasp the scope of the project? Hell. No.
Example 3:
Let’s assume you are the developer. You pulled it off! Everything just works! You’ve solved all of the issues I just explained.
Then the client hires an editor to post a new page.
Now you get to explain your complicated custom-built hack-together pseudo-multisite. Your instructions on how to update each site have a bunch of asterisks, notes, exceptions. Nobody wants that.
Chapter 2: Should we use a multisite instead?
That’s more reasonable, but still dangerous and can become costly.
You should immediately ask: Do you really need users have a significant amount of account data in sync? That is the ONLY reason you should use a multisite.
In the past I regretfully built a multisite so that two websites could use the same theme. It was convenient that admins could flip between them using the admin bar. The minute the client requests that Site A have a certain feature, your theme becomes fragmented. Hundreds of conditions later, it’s difficult to track down features and easy to make updates to the wrong website.
The benefit is that users can use the same login. Their WooCommerce billing address will be shared between both sites. You can even have control over which users can access which site, and with different capabilities.
Then the limitations show up. Users on Site A cannot use their saved card data on Site B because, for some reason, the plugin you use stores that data in a custom table. Or perhaps the plugin checks the domain to make sure it isn’t a copy of the site for development/staging. You need to find workarounds.
At some point you might find yourself thinking “wouldn’t two separate sites work better than this?”.
Chapter 3: Should we use two separate websites?
Two separate websites might sound tedious. Imagine all of your administrators having to sign in twice. What if they update a password on one site but not the other? What if their email address changes but they forget to update the other site?
The answer to most of these questions: Just deal with it. It’s not so bad, and often easy to correct account issues.
If you insist, you can completely solve all login/email/username discrepancies by using a single sign on plugin. You could use Google oAuth or one of the hundreds of already built for this purpose. You could even use Jetpack if you want to use WordPress.com as your login.
Question: “What If I want to make the same changes on both sites?”
Answer: Then make the changes twice!
It might help to re-think your own question. How often do you make the same change to two different websites? More often than you make changes to just one website? Probably not.
Two separate websites is actually a great option. It’s a little tedious sure, but simpler is easier to maintain and update.
There are other benefits too, like if one website is sold or branches off you could easily transfer it to a new host under new ownership.
In conclusion
Use two separate websites unless you have significant benefits from using a multisite.
Multisites are great only when you can leverage many of their benefits.
Using one website with two domains only makes sense in extremely niche scenarios. You will go over your cost estimates, so pad them well. I really can’t recommend this option personally unless I’ve thoroughly reviewed the entire scope of the project. Even then it might still be a bad idea. I have only executed this method properly once, it works great if you overlook the hundreds of complications involved.
Side note: What about merging two sites into a multisite?
This can be done. I have pulled it off successfully multiple times. Once both sites were membership sites with WooCommerce orders. It can be extremely technical. If you are not strongly familiar with MySQL I do not recommend this.
The problem is that user IDs from both sites will likely clash if you were to simply merge them. To solve that you’ll need to adjust the AUTO_INCREMENT values of the wp_user and wp_usermeta of Site A. You need to give enough room for Site B’s user and usermeta data.
Then you’ll need to transform all the user IDs from Site B so they start where Site A left off. That can also be complicated. Transforming Site B’s user #1 to instead be user #101 sounds reasonable. But what if Site B already has user #101? An easier tactic is to replace IDs from highest to lowest.
Your work isn’t done there, because you also need to update all the user ID references throughout the entire database from Site B.
Replacing IDs isn’t easy. Replacing user #230 to #530 without thinking ahead might replace a phone number 555-230-000 to 555-530-0000. You need to replace specific columns of specific tables, and know which meta keys for users, but also posts, form entries, woocomerce orders, etc. WordPress’s database does have “post_author” or “user_id” columns for some tables. But for metadata, you are looking at the “meta_value” column. You need to know which meta keys reference a user ID and not just a regular number.
If you forget to replace a user ID reference then users from Site A might suddenly see they have orders from a user on Site B because those users once shared the same ID.
Leave a Reply