Man this information is just littered everywhere and it is nearly impossible to figure out and has taken me three months of wandering the Internet, but for most modern installations, you really want three levels of flexibility:
- Lots of different domain names pointing to the same base site. In these modern times, you want to have all variants of your domain name point to the same place. So if your domain is `nice.com`, then you also want to own `nice.org`, `nice.app`, `trynice.com` and so forth
- You want to have lots of landing pages, so you can test various response rates, so you want `randomsite.com` to point to `nice.com/test so that you can easily set different tests and they all point to a place you can manage.
- If you are managing lots of startups, having a separate installation for each is a real pain. So you want the configurations to be as standard as possible.
So what you need to do is actually a pretty complicated dance between:
- The Registrar. In this case we are using Namecheap for URL redirects. The main reason for this is a weakness in the DNS specification. That is you cannot redirect a root domain record because you canât use CNAME for the root domain. Also this is the easy place to just do all the redirections and donât need to touch anything else. So buy your domain and then just go to `Domains > Details > Redirect Domain`. You actually need two redirections. First for the main and then a wildcard Redirect entry to catch everything else. Now if you are doing landing pages by yourself, then you need to do this here as the DNS doesnât support it, so if you have a place like `https://yoursite.com` you can point it to a specific place like `https://mysite.com/landing/123`,
- Domain Name Service. For the domains that are real. That is, they are not use domains that you have to prevent people from getting confused, you then need to connect the registrar to a Domain name server. This can be AWS Route 53 or CPanel. Assuming you are using Digital Ocean, then you create first an A name for the root domain say `name.com`. This needs to be a real IP address. You should create a static IP address now in the network section so that you can change the backing server and the public IP address doesnât change. Then you can use CNAMEs for www going to the A record. Also if you are using Instapage, it handles the URL directions at this level so you can put `test.yoursite.com` to the Instapage server, currently `secure.pageserve.co`
- The Multisite WordPress. Now you have most of it setup, but if you are doing a lot of experimentation, then you should really use Multisite WordPress. As of WordPress 4.5, this Multisite WordPress called MU WordPress is now integrated and with DigitalOcean, this is actually just a Bitnami image (unlike Lightsail where you have to enable it manually :-(). Why use it, itâs because common setup means that you just have one place for all the plugins and other security things. You donât have to do it over and over. It is also way cheaper for lots of test sites. Because you can run quite a few sites in a $5/month droplet. Note that the web often talks about WordPress MU Domain Mapping plugin. YOu donât need this, itâs just built in. Actually setting it up is bizarrely complicated. You first create a `New Site` and you should make sure to set this up as a Domain (vs Directory site) and then you give it a name you will never see like `new.host.com` and then when you go back to the network administration, you can replace it with `new.com`. finally you also need to ssh into the box and make sure to run `certbot` if you are using Digital Ocean (you use bncert-tool if you are using Lightsail). If you have DNS setup properly, it actually reads off that and sets up a SSL certificate that works for every domain in your MU WordPress setup.
Getting all this working is a pain, but now that it is done, it’s easy to host new sites. Of course, the simpler way would be to just setup up multiple Hugo/Netlify accounts and then you have something manageable and easy.
