TYPO3 Multi-Domain Setup: Mastering a Base Installation for Multiple Websites

Learn how to efficiently manage multiple websites via a single TYPO3 installation. From DNS and Apache to TYPO3 – the complete journey of an HTTP request.

Overview

  • DNS resolves domains to IP addresses and forms the global routing foundation for multi-domain setups.
  • Apache Virtual Hosts route incoming traffic to the correct TYPO3 site based on the Host header.
  • TYPO3 Site Management handles any number of domains via a single installation with its own configuration per site.
  • An HTTP request passes through the browser, DNS, Apache, and TYPO3 – this article illustrates every step of the journey.

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?

Important to understand

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:

FeatureA-RecordCNAME-Record
Points toIP address (123.45.67.89)Another domain name
DNS-Lookups1x (optimal)2x+ (slower)
Performance★★★★★ Best★★★☆☆ Delayed
For primary domain
Combinable with MX records
Recommended for multi-domain
Avoiding CNAME Errors

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:

Advantages:
Minimal DNS lookup time (single query)
Compatible with MX/TXT/SPF records
No DNS chain dependencies
Best performance

Performance Tip

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

You update an A-record with your DNS provider. The authoritative nameserver has the change immediately.

ISP Cache Refresh

DNS resolvers of Internet Service Providers update their caches based on TTL values.

Global Propagation

Most DNS servers worldwide have the new record. Regional differences may occur.

Complete Propagation

All DNS servers have updated records. Old caches have expired.
Testing Propagation

Use tools such as DNS Checker, Google Admin Toolbox Dig or the CLI tool dig to verify global DNS propagation:

Web-based tools:

Google Admin Toolbox Dig Interface

The Google Admin Toolbox Dig enables DNS lookups directly in the browser – ideal for quick checks without terminal access.


CLI-Tool:


Part 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

The 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.php that processes all requests is located
  • Important: This must be an existing directory that Apache has read access to

Interaction in practice:

  1. Browser sends a request to www.projekt-b.com
  2. Apache receives the request and reads the Host: www.projekt-b.com header
  3. Apache searches all Virtual Hosts for ServerName or ServerAlias = www.projekt-b.com
  4. Match found! → Apache uses the configured DocumentRoot /var/www/typo3
  5. All further file accesses occur relative to /var/www/typo3
Common Error: AllowOverride None

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:

When to use separate DocumentRoots?
  • 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

Create a root page in the page tree for each website. Under "Page properties → Behaviour", enable the option "Use as Root Page".

Open Site Management

Navigate to "Site Management → Sites". The module displays all root pages that do not yet have a site configuration.

Create Site Configuration

Click "Add new site configuration" on the first root page. Assign a unique site identifier (e.g., "company_a").

Define Entry Point

The critical step: Enter the full domain under "Entry Point": https://www.firma-a.de/ – this is the connection!

Configure Languages

Add at least one language (e.g., German with locale "de_DE.UTF-8"). Set the entry point to "/".

Repeat for Additional Sites

Repeat steps 3-5 for each additional domain/root page, each with its own entry point.

The config.yaml in Detail  

TYPO3 stores every site configuration as a YAML file. Here is the structure for our Company A:

Key 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)

Version Control for Site Configs

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:

Important 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  

Most Common Error: Forgetting the Trailing Slash

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

Create A-records for all domains. Use a TTL of 3600 seconds. Wait 24-48h for complete propagation.

Set up Apache Virtual Host

Create the Virtual Host configuration with ServerName and ServerAlias. Enable SSL with Let's Encrypt. Test with curl.

Configure TYPO3 Sites

Create root pages in the page tree. Configure entry points in Site Management. Test each domain in the browser.

Monitoring & Optimisation

Implement uptime monitoring. Configure log rotation. Optimise Apache performance (mod_cache, HTTP/2).

Best Practices for Production Operation  

Production Checklist

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:

Let's talk about your project

Locations

  • Mattersburg
    Johann Nepomuk Bergerstraße 7/2/14
    7210 Mattersburg, Austria
  • Vienna
    Ungargasse 64-66/3/404
    1030 Wien, Austria

Parts of this content were created with the assistance of AI.