Introduction
You are facing a challenge familiar to many companies: managing multiple digital presences centrally – from the main website and product pages to event microsites. The good news is that with TYPO3, this is not only possible but also extremely efficient.
A multi-domain setup with TYPO3 means: one installation, unlimited possibilities. You save on hosting costs, reduce maintenance efforts, and retain full control over your digital infrastructure.
In this guide, we will follow an HTTP request on its journey through the system – from the browser input to the final content delivery. You will understand not just how the configuration works, but more importantly, why.
Table of Contents
Part 1: The Anatomy of a URL – What Your Browser Actually Sends
Before configuring servers, we need to understand the language of the web. Every web request begins with a URL – let's look at what actually happens in the address bar.
URL Components in Detail
Let's take a complex URL apart:
URL Anatomy: What is processed where?
The fragment (#absatz3) never leaves your browser. The browser sends all other components as an HTTP request to the server. The server only sees: GET /folder1/folder2/datei.html HTTP/1.1 with the Host header myserver.at.
The Request Journey at a Glance
Before diving into the details, here is the overall process at a glance:
The complete request lifecycle
Let's examine each phase in detail.
Part 2: DNS – The Global Address Book of the Internet
DNS (Domain Name System) is the foundation of all web communication. Browsers only understand IP addresses – DNS translates human-readable domain names into machine-readable IPs.
A-Record vs CNAME Record: The Crucial Choice
There are two DNS record types for multi-domain setups. The choice has massive implications for performance and functionality:
| Feature | A-Record | CNAME-Record |
|---|---|---|
| Points to | IP address (123.45.67.89) | Another domain name |
| DNS-Lookups | 1x (optimal) | 2x+ (slower) |
| Performance | ★★★★★ Best | ★★★☆☆ Delayed |
| For primary domain | ✓ | ✕ |
| Combinable with MX records | ✓ | ✕ |
| Recommended for multi-domain | ✓ | ✕ |
Critical: A primary domain (e.g., firma-a.de) must not have a CNAME if you require MX records for email. DNS standards prohibit this combination. Your email reception would fail completely!
DNS Configuration: Practical Implementation
For our multi-domain setup with firma-a.de and projekt-b.com, you will need the following DNS records:
Optimal configuration for multi-domain:
; Primary domains
firma-a.de. IN A 123.45.67.89
www.firma-a.de. IN A 123.45.67.89
projekt-b.com. IN A 123.45.67.89
www.projekt-b.com. IN A 123.45.67.89
; Email records work in parallel
firma-a.de. IN MX 10 mail.firma-a.de.
projekt-b.com. IN MX 10 mail.projekt-b.com.Advantages:
Minimal DNS lookup time (single query)
Compatible with MX/TXT/SPF records
No DNS chain dependencies
Best performance
Set the TTL (Time to Live) to 3600 seconds (1 hour) for production systems. For planned changes, reduce this to 300 seconds (5 minutes) 24 hours in advance to enable faster propagation.
Understanding DNS Propagation
DNS changes are not immediately visible worldwide. Here is what happens:
DNS Record Change
ISP Cache Refresh
Global Propagation
Complete Propagation
Use tools such as DNS Checker, Google Admin Toolbox Dig or the CLI tool dig to verify global DNS propagation:
Web-based tools:

The Google Admin Toolbox Dig enables DNS lookups directly in the browser – ideal for quick checks without terminal access.
CLI-Tool:
dig firma-a.de +short
# Output: 123.45.67.89Part 3: Apache Virtual Host – The Intelligent Traffic Director
DNS has provided the IP address – now Apache receives the HTTP request. Its task is to route requests for hundreds of potential domains to the correct directories.
Virtual Hosts: One Server, Many Websites
Imagine Apache as the reception hall of an office building. The IP address is the street address. The Host header in every HTTP request is like the company name on an envelope. Apache checks its configuration and routes the request to the correct 'office' (DocumentRoot).
Apache request routing via Host header
Name-Based Virtual Hosts: The Configuration
Name-based Virtual Hosts allow multiple websites on a single IP address – distinguished only by the domain name in the HTTP header.
File: /etc/apache2/sites-available/typo3-multisite.conf
<VirtualHost *:80>
# DocumentRoot: The central entry point for all domains
# All requests land here, regardless of the requested domain
DocumentRoot /var/www/typo3
# ServerName: The primary domain of this Virtual Host
# Apache uses this if no other domain matches
ServerName www.firma-a.de
# ServerAlias: All other domains that also land here
# Space-separated list of all additional domains
ServerAlias firma-a.de www.projekt-b.com projekt-b.com
# Logging for debugging and monitoring
ErrorLog ${APACHE_LOG_DIR}/typo3_error.logThe three most important directives explained:
ServerName: The primary domain for this Virtual Host
- Defines the primary domain that Apache links to this Virtual Host
- Serves as a fallback if no exact domain match is found
- Example:
ServerName www.firma-a.de - Apache also uses this for redirects and self-referential URLs
- If a request arrives without or with an invalid Host header, the first Virtual Host with a matching ServerName takes over
ServerAlias: Additional domain names for the same website
- Allows multiple alternative domains pointing to the same Virtual Host
- Perfect for www variants or multiple domain names for a website
- Example:
ServerAlias firma-a.de www.projekt-b.com projekt-b.com - Domains are separated by spaces
- Apache checks ServerName first, then ServerAlias – the first match wins
- Wildcards are possible:
ServerAlias *.firma-a.de(for all subdomains)
DocumentRoot: The file system path to the website files
- The absolute path on the server where the website files are located
- Example:
DocumentRoot /var/www/typo3 - Apache serves all matching requests from this directory
- Apache looks for the requested file relative to this path
- For TYPO3: This is where the
index.phpthat processes all requests is located - Important: This must be an existing directory that Apache has read access to
Interaction in practice:
- Browser sends a request to
www.projekt-b.com - Apache receives the request and reads the
Host: www.projekt-b.comheader - Apache searches all Virtual Hosts for
ServerNameorServerAlias=www.projekt-b.com - Match found! → Apache uses the configured
DocumentRoot /var/www/typo3 - All further file accesses occur relative to
/var/www/typo3
If AllowOverride None is set, Apache ignores TYPO3's .htaccess. Symptom: 404 errors for all pages except the homepage. Solution: Set AllowOverride All.
Multi-Domain with Separate DocumentRoots
Sometimes you may want different TYPO3 installations per domain. Here is the advanced configuration:
# Virtual Host 1: Company A
<VirtualHost *:443>
DocumentRoot /var/www/firma-a
ServerName www.firma-a.de
ServerAlias firma-a.de
<Directory /var/www/firma-a>
Options FollowSymLinks
AllowOverride All
Require all granted
</Directory>
</VirtualHost>
# Virtual Host 2: Project B
<VirtualHost *:443>- Single installation: Shared hosting, shared extensions, central maintenance
- Separate installations: Completely isolated projects, different TYPO3 versions, separate teams
Part 4: TYPO3 Site Management – The Content Engine
Apache has forwarded the request – now TYPO3 takes over. The CMS must decide: which website should TYPO3 deliver for this domain?
The Foundation: The TYPO3 Page Tree
TYPO3 manages all content in a hierarchical page tree. For every independent website, you need a root page.
TYPO3 Multi-Site Page Tree Structure
Site Management Module: Modern Configuration
Since TYPO3 v9, the Site Management module has replaced complex TypoScript configurations. It defines Entry Points – the link between a domain and a root page.
Create Root Pages
Open Site Management
Create Site Configuration
Define Entry Point
Configure Languages
Repeat for Additional Sites
The config.yaml in Detail
TYPO3 stores every site configuration as a YAML file. Here is the structure for our Company A:
# typo3conf/sites/firma_a/config.yaml
rootPageId: 1
base: 'https://www.firma-a.de/'
# Language configuration
languages:
-
title: Deutsch
enabled: true
languageId: 0
base: /
typo3Language: de
locale: de_DE.UTF-8
iso-639-1: de
navigationTitle: DeutschKey Concepts:
• rootPageId: The Page UID of the root page
• base: The entry point – TYPO3 matches HTTP requests against this value
• languages: Multi-language support
• errorHandling: Custom error pages
• routes: Static routes (robots.txt, sitemap.xml)
The config.yaml files should be version-controlled (Git). This allows you to:
- Track changes
- Perform rollbacks
- Synchronise configs across environments (Dev → Staging → Prod)
- Conduct code reviews for infrastructure changes
TYPO3 Request Matching: The Algorithm
This is how TYPO3 decides which site is responsible for a request:
TYPO3 Site Resolution Flow
Important: TYPO3 checks both base AND baseVariants. The first matching configuration wins. In the event of multiple matches, the alphabetically first config.yaml takes precedence.
Part 5: The Complete Request Journey – End-to-End
Let's track a complete request for www.projekt-b.com through all layers:
End-to-End Request Journey for www.projekt-b.com
Request Details: The HTTP Headers
What does the browser actually send? Let's take a look at the actual HTTP headers:
HTTP request from the browser:
GET / HTTP/1.1
Host: www.projekt-b.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: de-DE,de;q=0.9,en;q=0.8
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Upgrade-Insecure-Requests: 1Important for routing:
• Host: www.projekt-b.com – Apache and TYPO3 use this header for domain matching
• Accept-Language: Browser language preference (TYPO3 can react to this)
• Accept-Encoding: Server can compress the response (gzip)
Troubleshooting: Common Errors
The base value in the TYPO3 config.yaml must end with /:
base: 'https://www.firma-a.de/'
base: 'https://www.firma-a.de'
Domain matching will not work without the trailing slash!
Conclusion: Your Digital Infrastructure – Scalable and Future-Proof
You have mastered the complete architecture of a TYPO3 multi-domain setup. From the DNS layer and Apache Virtual Host to the TYPO3 site configuration – you now understand how the individual components seamlessly integrate.
What You Have Achieved
Performance
Optimal DNS configuration using A-records for minimal latency. No CNAME chains, direct IP routing. Your sites are accessible worldwide quickly.
Cost Efficiency
A single TYPO3 installation for any number of domains. Reduced hosting costs, shared extension management, central maintenance, and updates.
Maintainability
Central management of all websites. One update, one backup, one monitoring configuration. Your DevOps teams will love it.
Security
SSL/TLS configuration for all domains. HSTS, security headers, and modern TLS ciphers. Your visitors are protected.
Scalability
Unlimited expansion: Add new domains in minutes. No more complex migration projects. Your infrastructure grows with your business.
Flexibility
Individual configurations per site. Own languages, own templates, own extensions – all controllable from a central installation.
The Three Layers at a Glance
The three architectural layers interacting
Your Next Steps
Configure DNS
Set up Apache Virtual Host
Configure TYPO3 Sites
Monitoring & Optimisation
Best Practices for Production Operation
DNS:
- A-records for all domains and www subdomains
- TTL to 3600 seconds (1 hour)
- CAA records for SSL providers (Let's Encrypt)
- SPF/DKIM/DMARC for email domains
Apache:
- SSL/TLS with automatic renewal (certbot)
- HTTP/2 enabled (
a2enmod http2) - Gzip/Brotli compression (
a2enmod deflate) - Security headers (HSTS, X-Frame-Options, CSP)
- Log rotation configured
TYPO3:
- Site configs version-controlled (Git)
- Separate config.yaml per site
- baseVariants for staging/dev
- Error handling with custom pages
- robots.txt & sitemap.xml per site
- Multi-language configured
Monitoring:
- Uptime checks for all domains (e.g., UptimeRobot)
- SSL certificate expiry alerts
- DNS monitoring (e.g., DNSPerf)
- Apache logs aggregated (e.g., ELK Stack)
- Centralised TYPO3 error logging
Support & Further Resources
Official Documentation:
Tools:
- DNS Checker – Check global DNS propagation
- SSL Labs – Test SSL configuration
- GTmetrix – Performance analysis