How TYPO3 Handles Multiple Sites

TYPO3 is one of the few open-source CMS platforms designed from the ground up to serve many distinct websites from a single codebase and database. Instead of installing the core once per brand, you build a single instance and represent each website as a separate root page inside the page tree. A root page is any page that carries the Is root of website flag in its page properties. Each of these roots becomes an entry point that TYPO3 binds to a hostname through a Site Configuration.

This model exists because TYPO3 was built for agencies and organizations managing portfolios of sites that share editors, templates, and extensions. The shared instance keeps one set of PHP files, one composer.json (or one non-Composer install), one extension set, and one cache layer, while content and domains stay isolated per root page. On shared hosting this matters a great deal: fewer installations means fewer copies of the framework consuming inodes, one OPcache footprint, and a single upgrade path rather than five.

The alternative TYPO3 supports is fully separate instances, where you place an independent copy of the core in its own document root with its own database. You would choose that path when two sites need different TYPO3 major versions, conflicting extensions, or hard security separation between clients. Both approaches are legitimate and both work within an unprivileged hosting account, because everything is driven by files under your home directory, database entries in phpMyAdmin, and domain routing in your control panel. Nothing here requires root, service restarts, or edits to files under /etc/.

The practical decision usually comes down to this: if the sites share editors and a template family and can stay on the same TYPO3 version, use one instance with multiple Site Configurations. If they must diverge in version or extensions, or belong to unrelated account owners, use separate instances. Mixing the models on one hosting account is fine as long as each document root is clean.

Mapping Domains and Subdomains in the Control Panel

Before TYPO3 can serve a hostname, the hostname must actually reach your document root. That is a control-panel task, not a TYPO3 one. In cPanel Jupiter, the primary domain already points at public_html. To add another brand, open Domains and create an Addon Domain; to add a subdomain such as shop.example.com, open Domains or Subdomains and create it. The important choice is the document root. For a shared TYPO3 instance, point every addon domain and subdomain at the same document root as the main site, for example /home/user/public_html. In DirectAdmin Evolution the equivalents are Domain Setup for additional domains and Subdomain Management for subdomains; set the additional domain's path to reuse the main public root when you want one TYPO3 to answer for all of them.

Pointing several domains at one document root is what lets a single TYPO3 index.php inspect the incoming Host header and select the matching Site Configuration. If instead you let cPanel create a separate folder like public_html/shop.example.com, you have effectively signaled that you want a separate instance living in that folder, which is the other valid pattern discussed below.

Make sure each hostname has a working SSL certificate. On managed hosting AutoSSL usually issues certificates automatically once DNS resolves, but confirm under Security > SSL/TLS Status in cPanel or SSL Certificates in DirectAdmin that every addon domain and subdomain is covered. TYPO3 Site Configurations frequently force HTTPS, and a missing certificate on a subdomain produces redirect loops that look like a TYPO3 bug but are really a TLS gap.

Because TYPO3 routes through a front controller, your document root needs the shipped .htaccess. TYPO3 provides a well-tuned file; if yours is missing, the minimum LiteSpeed-compatible rewrite that sends all non-file requests into the framework looks like this:

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php [QSA,L]

# Block direct access to sensitive TYPO3 paths
RewriteRule ^(?:typo3conf|typo3temp/var)/ - [F]

Keep the official TYPO3 .htaccess where possible, since it also sets caching headers that LiteSpeed honours. Because all hostnames share this file, you do not need per-domain rewrite blocks; the routing decision happens inside TYPO3.

Creating Site Configurations Inside TYPO3

With domains pointing at the shared root, the actual site mapping is done in the TYPO3 backend. Log in at /typo3, create or identify the page that will be the root of each website, and in the page properties on the Behaviour tab enable Use as Root Page. Then open Site Management > Sites. TYPO3 will list root pages that lack a configuration; choose Add site configuration for each one.

In the site record, the two fields that matter most are the Entry Point (the full URL such as https://shop.example.com/) and the Site Identifier, a short machine name like shop. For multilingual brands you add languages here, each with its own base path or domain. TYPO3 writes each configuration to config/sites/<identifier>/config.yaml (or typo3conf/sites/ on older non-Composer installs). You can open these files in File Manager to confirm the base URL, but edit them through the backend to avoid YAML indentation errors that break routing.

A representative config.yaml for a subdomain site reads:

base: 'https://shop.example.com/'
rootPageId: 12
languages:
  - title: English
    enabled: true
    languageId: 0
    base: /
    locale: en_US.UTF-8
    navigationTitle: English
    flag: us

After saving, clear all caches from the Flush TYPO3 and PHP Cache broom icon in the top toolbar, because routing and site data are cached aggressively. If a newly added subdomain shows the wrong brand, a stale routing cache is the usual cause. When a site returns a blank page or a 500, check the request-level log your account can actually see: the error_log file that LiteSpeed writes into the document root or the affected directory, plus TYPO3's own log under var/log/. Raise memory for heavy imports with a .user.ini in the document root using memory_limit = 256M rather than touching any server-wide config, and confirm your PHP version through cPanel MultiPHP Manager or the DirectAdmin/CloudLinux Select PHP Version selector meets the TYPO3 requirement.

Shared Instance Versus Separate Instances

Everything above assumes one TYPO3 answering for many hostnames from a shared database. That is the efficient default for related sites. When isolation wins over efficiency, install a second, independent TYPO3 in its own directory. Create the addon domain or subdomain with its own document root, for example /home/user/shop.example.com, create a fresh database and database user in cPanel MySQL Databases or DirectAdmin MySQL Management, then run the TYPO3 installer against that folder. Each instance keeps a separate config/system/settings.php holding its own database credentials, so the two never share tables.

Separate instances cost more inodes and require you to patch each one individually, which is the trade-off for being able to run different major versions or client-specific extension stacks side by side. Resource ceilings apply per account regardless of how many instances you run, so several TYPO3 copies still compete for the same PHP worker pool, CPU, and I/O allotment. If you notice slowdowns as sites multiply, the diagnostics are the same as for any application under these limits; the walkthrough in our guide on diagnosing CPU, RAM, PHP workers, I/O, and inode bottlenecks transfers directly to a multi-instance TYPO3 setup. Choose the shared-instance model whenever the sites can live on one version, and reserve separate installs for the cases that genuinely demand hard separation.