Extra names and subdomains

One website can answer on more than one name. You registered mycompany.com, later mycompany.co.uk as well, and you want both to show the same site. Or you have mycompany.com and want shop.mycompany.com beside it as a separate webshop. Those are two different things, and the panel keeps them apart.

• An extra name belongs to a website that already exists. No second site, no second folder of files, no second certificate. Visitors see the same pages — or they are redirected to the main name.
• A subdomain is a website of its own: its own folder, its own PHP version, its own certificate. The panel simply knows which site it belongs to, and shows it that way.

Coming from DirectAdmin: an extra name is what DA calls a pointer, and a subdomain is a subdomain there too. A migration carries both across — you do not have to recreate them.

Adding an extra name

Panel — open the account, go to Websites and click the website. The panel that slides open has an Extra names section with an Add a name button. There are four fields:

The last two are on by default. That is deliberate: somebody arriving from DirectAdmin expects mail to the extra name to keep working, and this is exactly what makes it keep working.

Shell — the same thing, in one line:

corectl domain alias add mycompany.com mycompany.co.uk

And this is what the list looks like afterwards:

corectl domain alias list mycompany.com

DOMAIN                           ALIAS                            KIND      MAIL  ZONE  SSL
mycompany.com                    www.mycompany.com                alias     on    off   active
mycompany.com                    mycompany.co.uk                  alias     on    on    active

Redirecting instead of showing

Sometimes you do not want two names showing the same site. You have moved from an old name to a new one and want everybody — and Google — to end up on the new one. Then choose Redirect (301):

corectl domain alias add mycompany.com oldcompany.com --redirect

$ curl -sI http://oldcompany.com/contact
HTTP/1.1 301 Moved Permanently
Location: https://mycompany.com/contact

Note the path: /contact is kept. Somebody following a link to a deep page of the old name lands on that same page of the new name, not on the front page.

"Waiting for DNS" — what that means

An extra name can say waiting for DNS instead of in certificate. That is not an error, and nothing is broken.

A certificate is only issued for names that point at this server right now. If you have just added the name and its DNS is still with your old provider, the certificate authority cannot check it. Rather than failing the whole certificate — including your main domain, which was doing fine — the name is skipped:

• your main domain keeps its valid certificate;
• the extra name already works over http://;
• no request is wasted at Let's Encrypt.

As soon as the DNS is right, the next request picks it up. That happens by itself at the nightly renewal, or you can start it yourself:

corectl ssl issue mycompany.com

[corecp] mycompany.co.uk now points here and is included in the certificate
[corecp] requesting SSL for [mycompany.com www.mycompany.com mycompany.co.uk] ...
[corecp] certificate active for [mycompany.com www.mycompany.com mycompany.co.uk]

One thing to know if you have a wildcard certificate: *.mycompany.com does not cover anything.mycompany.co.uk. That is a different main domain, so it is a separate name in the certificate. Subdomains of an extra name have to be added as extra names themselves.

Mail for an extra name

With Carry the mail too on, mail to any address at the extra name arrives in the mailbox with the same name on your main domain. info@mycompany.co.uk lands in info@mycompany.com. There is no second mailbox to create and nothing to configure.

If you do not want that — because the mail for that name belongs to a different company, say — switch it off:

corectl domain alias set mycompany.com mycompany.co.uk --mail off

From then on the server refuses mail to that name at the door, with an error the sender sees. That is on purpose: mail that quietly disappears is worse than mail that is refused, because at least a refusal tells the sender to look elsewhere.

Making a subdomain

A subdomain is a name under your website: shop.mycompany.com, blog.mycompany.com, test.mycompany.com. In the panel you create it with the same button as any website — Add a website — typing the full name.

corectl domain add shop.mycompany.com --account myaccount

It then appears in the website list indented under its main domain, labelled subdomain, so you can see at a glance what belongs together.

A subdomain is a full website:

• its own folder — domains/shop.mycompany.com/public_html;
• its own PHP version — you can put the shop on 8.4 while the main site runs 8.5;
• its own certificate — automatically, like any other website;
• its own statistics, its own log files, its own backups.

One thing a subdomain does not get: mail of its own. Your main domain's mailboxes already cover the addresses people actually use, and a stray mail address on a subdomain mostly creates confusion. No hosting panel does this differently.

Removing a subdomain

corectl domain remove shop.mycompany.com --purge

The main domain carries on. --purge also throws away the subdomain's files; leave it off and they stay, so you can recreate the subdomain later without having lost anything.

Removing also wipes the request history of that name: how often a certificate request failed and how long the server waited afterwards. That is worth exactly one thing, and it is a pleasant one — if a subdomain went wrong a few times because its DNS was not right yet, a subdomain you recreate later starts with a clean slate and the server tries again straight away instead of waiting half an hour first.

Where your website is served from

Every website has one directory visitors are shown: the document root. By default that is domains/<your-site>/public_html, and for most sites it stays that way.

Sometimes the default is wrong. Modern frameworks — Laravel, Symfony — put only a public directory online and deliberately keep the rest of the code out of it. And anyone who works with releases puts each rollout in a directory of its own and lets one link point at the newest. For both of those you can move the document root.

In the panel: Accounts → your account → Websites, click the website and choose Manage document root.

1. You see where the site is served from now.
2. You click through your own home to the directory it should become.
3. See what changes — the panel asks the server: which names will serve the new directory, which installation sits under it, what happens to a protected folder, and what does not change.
4. Only then do you move it. And one button puts it back.

corectl domain docroot mysite.com
corectl domain docroot preview mysite.com --path domains/mysite.com/public_html/public
corectl domain docroot set mysite.com --path domains/mysite.com/public_html/public --confirm
corectl domain docroot revert mysite.com --confirm

Nothing is moved. Repointing is a change of address: the old directory stays exactly as it was. That is also why going back is one action rather than a restore.

What you may choose, and what you may not

Any directory inside your own home, with five exceptions — and every one of them is about a document root being published: whatever is in it, the server hands to anybody who knows the address.

A subdirectory of logs or tmp is fine; what is refused is the directory that holds the lot. And a path that tries to climb out of your home with .., or a link that points outside it, is refused with the reason attached.

This list stops the wrong directory being published by accident. It does not stop what you put in your document root yourself: a link you make inside it is followed by the web server, so whatever you put there is online. Do not keep keys, backups or configuration files in it.

Working with releases

A link may be the document root, as long as it stays inside your home. That is exactly the shape a rollout has:

$ ls -l ~/domains/mysite.com/
public_html
releases/
current -> /home/myaccount/domains/mysite.com/releases/2026-09-06

Point the document root at current, and from then on the link decides what the site serves. Point it at the next release and the site is there — without touching the panel at all. The panel always shows both: the link, and the directory it currently leads to.

One detail: the web server remembers the path for a few seconds, so right after the switch it may still show the previous release. Nothing needs restarting; wait a moment and refresh.

A few things worth knowing

• A DirectAdmin-style subdomain does not follow. If a subdomain sits inside its parent's directory, it stays where it is when you move the parent's document root. That is deliberate — following would point it at a directory nobody created — and the preview says so.
• Your certificate does not notice. It belongs to the name, not to the directory, and renewal takes a route of its own.
• Neither does your backup. It copies your whole home, so both the old and the new directory keep being included.
• If the new directory is empty, the preview says so beforehand. Put an index.html or index.php there first.
• This is administrator work. The button is there for your hosting provider and for a reseller. And the assistant may look up where your site is served from, but never choose a different directory itself: that can put private files on the internet, and putting it back does not undo that.

What is not here: hotlink protection

DirectAdmin and cPanel have a hotlink protection switch, meant to stop other sites from loading your images directly. CoreCP deliberately does not have that switch, and does not carry it over during a migration either.

The technique behind it looks at the referer field the browser sends. Since 2020 that field is shortened or missing in most browsers — with a privacy extension, behind a noreferrer link, in a PDF viewer, in a mail client. The result is that such rules block precisely the wrong visitors: your own customers, who then see an empty box where your product photo should be. And you only find out when somebody calls.

What does work, if somebody really is pulling at your bandwidth:

• signed links with an expiry, so a copied URL does nothing an hour later;
• a CDN with token protection, which does the same at the edge;
• a rate limit per IP address.

If you are coming from DirectAdmin, the migration report says so too: hotlink configuration is NOT carried over. Your .htaccess travels with your files, so the rules are still there — you can remove them at your leisure.

What a visitor sees while there is nothing there yet

A new website — a main name, a subdomain, or a folder you made yourself — is empty for the first few minutes. A visitor still gets neither a bare error nor a listing of files: from the first moment there is a tidy "a website is on its way" page.

That page carries your hosting provider's brand, not ours. It loads nothing else from the internet, so it still works when something is broken.

You do not have to do anything for it, and you do not have to remove it either: the moment you put your own index.html or index.php in the folder, it is gone. If you install WordPress, the installation clears the placeholder itself.

ls ~/domains/mysite.com/public_html
# index.html   ← the placeholder

If you delete it by hand it does not come back — an empty folder stays an empty folder. There are three more of these pages: one for a page that does not exist, one for something going wrong on the server, and one for hosting that is temporarily suspended. They carry the same brand.

See also

• SSL and certificates — how your website's certificate works.
• Setting up email — mailboxes, aliases and forwarding addresses.
• Managing DNS records — if your DNS lives somewhere else.

And the nameservers themselves?

Your website's names are above. The nameservers that hand those names out are something else: they belong to your hosting brand rather than to one site. If you resell hosting, Your own nameservers explains how to create ns1.yourbrand.com and have it checked.

"PHP version is not installed" when you add one

Every website gets the server's default PHP version unless you pick one. If that version is not on the machine the server refuses — a website pointing at a PHP that is not there serves nothing.

Since 16 August 2026 the message also says which kind of PHP it could not find:

corectl: PHP version "84" is not installed for the lsphp SAPI (corectl php add 84)

That lsphp (or fpm) is not a detail: a LiteSpeed server runs PHP in a different shape than an nginx or Apache one, and the versions are kept per shape. On a LiteSpeed server the check used to read the wrong list, so adding a website failed on a version that was in fact installed. If you see this, the fix is one line on the server: corectl php add 85. Ask your administrator if you do not run it yourself.