Zum Inhalt springen 
Ich zeige Schritt für Schritt, wie ich eine IONOS Subdomain anlege, DNS korrekt setze und die Adresse sauber teste. So richte ich Ziele, SSL und Weiterleitungen ein, halte die Struktur übersichtlich und löse typische Fehler ohne Umwege.
Zentrale Punkte
Vor dem Start halte ich die folgenden Erfolgsfaktoren im Blick und arbeite sie der Reihe nach ab, damit die Subdomain schnell und stabil läuft.
- Setup: Login, Domain wählen, Subdomain benennen
- DNS: A-, AAAA- oder CNAME-Record korrekt setzen
- SSL: Zertifikat je Subdomain aktivieren
- SEO: Sitemaps, klare Struktur, kein Duplicate Content
- Tests: Propagation abwarten, Ziel prüfen
Ich behalte bei jedem Projekt klare Namen, saubere DNS-Einträge und ein gültiges SSL im Fokus. Damit grenze ich Dienste, Tests und Live-Auftritte sauber ab. Ich dokumentiere jede Änderung, um später schneller anzupassen. Ich plane die Subdomain-Struktur so, dass spätere Erweiterungen leicht fallen. Ich prüfe die Erreichbarkeit von mehreren Standorten, bevor ich Inhalte aktiv bewerbe.
Was ist eine Subdomain? Kurz erklärt
Eine Subdomain erweitert die Hauptdomain um einen vorangestellten Hostnamen wie blog. So trenne ich Inhalte, Dienste oder Teams technisch und organisatorisch, ohne eine neue Domain zu kaufen. Beispiele sind blog.meinedomain.de, shop.meinedomain.de oder dev.meinedomain.de für Tests. Die Idee: Ich kapsle Funktionen und kann Ziele, SSL und Auswertung unabhängig steuern. Wer Begriffe und Optionen komprimiert nachlesen möchte, findet in dieser knappen Subdomain Definition zusätzliches Grundlagenwissen.
IONOS Subdomain anlegen: Schritt-für-Schritt
Ich melde mich im Kundenkonto an und öffne Domains & SSL, dann wähle ich die passende Domain aus. Im Subdomain-Bereich klicke ich auf Subdomain erstellen und vergebe einen kurzen Namen wie blog, shop oder kunden. Als Ziel bestimme ich entweder das Webverzeichnis der Hauptseite oder einen eigenen Ordner für eine eigenständige Anwendung. Für externe Dienste setze ich in den DNS-Einstellungen statt eines Ordnerziels einen CNAME oder A-Record auf die Zieladresse. Nach dem Speichern warte ich die DNS-Verbreitung ab, teste die Subdomain im Browser und prüfe Status und SSL in der Übersicht.
Bei IONOS nutze ich je nach Zweck diese Zieltypen: 1) Webspace-Verzeichnis für eigene Inhalte, 2) Weiterleitung (HTTP/HTTPS) auf eine andere URL, 3) App- oder Site-Verknüpfung, falls ein Baukasten/Shop angebunden ist, 4) Rein DNS-basiert, wenn ein externer Service angesprochen wird. Ich halte Pfadstruktur und Berechtigungen im Webspace konsistent, damit Deployments reproduzierbar bleiben. Für Staging-Instanzen aktiviere ich gezielt Zugriffsschutz, damit Suchmaschinen und Nutzer nicht versehentlich darauf landen.
DNS-Ziele und Records richtig setzen
Für Webinhalte verweise ich die Subdomain meist via A-Record auf eine IPv4-Adresse oder via AAAA-Record auf eine IPv6-Adresse. Läuft der Zielservice extern, setze ich oft einen CNAME, der auf den Host des Anbieters zeigt. Wichtig ist ein sinnvoller TTL-Wert, damit Änderungen schnell greifen und spätere Umstellungen nicht ewig warten. Ich kontrolliere in den DNS-Einstellungen, ob Hostname, Record-Typ und Ziel exakt übereinstimmen. Wer Schrittfolgen kompakt nachlesen möchte, nutzt den Leitfaden zu DNS-Einstellungen bei IONOS als Erinnerungshilfe.
Ich plane die TTL-Strategie: In Phasen mit vielen Änderungen setze ich eine niedrigere TTL (zum Beispiel 300–900 Sekunden), nach der Stabilisierung erhöhe ich sie wieder, um Caching zu nutzen. A und AAAA sollten parallel auf dasselbe System zeigen, sonst kommt es zu unterschiedlichem Verhalten je nach Client. CNAMEs vermeide ich dort, wo ich granulare Kontrolle über A/AAAA brauche oder Latenz minimal halten will. Kommt ein CDN oder Reverse-Proxy zum Einsatz, weise ich die Subdomain per CNAME auf den Anbieter und hinterlege die Ursprungs-IPs intern dokumentiert.
Für komplexe Setups delegiere ich Subzonen: Ich setze NS-Records für z. B. dev.meinedomain.de auf andere Nameserver, wenn ein Team die Entwicklungsumgebung eigenständig verwaltet. Dabei prüfe ich, dass keine doppelte Autorität entsteht (keine konkurrierenden Records in der übergeordneten Zone). Ich achte außerdem auf CAA-Records in der Hauptzone, falls die Zertifikatsausstellung eingeschränkt ist; die Subdomain erbt diese Regeln.
Weiterleitungen richtig aufsetzen
Ich unterscheide klar zwischen 301 (dauerhaft), 302/307 (temporär) und 308 (dauerhaft, Methode beibehalten). Für Subdomains, die nur weiterleiten sollen, nutze ich eine serverseitige Weiterleitung und lasse Pfade sowie Query-Strings nach Möglichkeit unverändert durchreichen. Maskierte Weiterleitungen vermeide ich, weil sie SSL, SEO und Sicherheit erschweren. Bei Umzügen plane ich Redirect-Matrizen: Subdomain-Quellen, Ziel-URLs, Statuscodes, Laufzeit. Ich halte die Kette flach (maximal ein Hop), um Performance und Crawling-Budget nicht zu belasten.
Wildcard-Subdomains und FTP-Zugänge
Wenn ich viele Subdomains dynamisch route, setze ich eine Wildcard wie *.meinedomain.de und zeige sie auf ein Standardziel. So landen auch noch nicht angelegte Hosts auf einer sinnvollen Seite oder einem Catch-all-Projekt. Für FTP-Zugänge verwende ich gern ftp.meinedomain.de und hinterlege einen CNAME auf die technische Serveradresse, damit Tools den Host leicht erkennen. Diese Konvention erleichtert Teamwork und dokumentiert Absichten bereits im Hostnamen. Ich halte zusätzlich Benennungen wie dev, staging oder test konsistent, um Teststände klar zu trennen.
Bei Wildcards beachte ich SSL: Je nach Tarif und Validierungsmethode wird ein Wildcard-Zertifikat benötigt, sonst schlägt die HTTPS-Verbindung fehl. Ich prüfe, ob bestimmte Hosts ausgenommen werden sollen, etwa wenn shop.meinedomain.de auf einen externen Anbieter zeigt. Wildcards sind mächtig, aber ich setze sie gezielt ein, um unbeabsichtigte Überschneidungen zwischen Hardcoded-Hosts und Catch-all zu vermeiden.
E-Mail auf Subdomains sinnvoll nutzen
Brauche ich eigene Postfächer für eine Subdomain (z. B. support.meinedomain.de), setze ich dedizierte MX-Records. Senden Dienste von einer Subdomain (etwa newsletter.meinedomain.de), ergänze ich SPF-Einträge und richte DKIM/DMARC analog zur Hauptdomain ein. So bleibt die Zustellbarkeit stabil und ich trenne Absenderidentitäten ordentlich. Ich vermeide, produktive Websubdomains gleichzeitig für E-Mail zu verwenden, damit ich Dienste sauber kapsel und Konflikte bei DNS-Records ausschließe.
Sicherheit und Zugriffsschutz
Ich schalte SSL konsequent für jede Subdomain aktiv und leite HTTP automatisch auf HTTPS um. Für interne Umgebungen setze ich zusätzlich Basic-Auth, IP-Restriktionen oder VPN-Zugriff, damit Suchmaschinen und Unbefugte nicht zugreifen. Ich prüfe Mixed-Content, HSTS und moderne Cipher Suites, um Browserwarnungen zu vermeiden. Für APIs hinterlege ich CORS-Regeln pro Subdomain, damit Frontends kontrolliert zugreifen. Wo sinnvoll, isoliere ich Sessions und Cookies pro Host, um Risiken durch breit gesetzte Cookie-Domains zu verringern.
Performance, Caching und CDN
Ich entscheide pro Subdomain, ob ein CDN oder Reverse-Proxy Mehrwert bietet: statische Inhalte, internationale Reichweite, DDoS-Schutz. Bei aktiven Caches plane ich Purge-Strategien und Versionierung (Dateinamen mit Hash), damit Deployments ohne harte Browser-Refreshs sauber live gehen. Serverseitig nutze ich Etags/Last-Modified und sinnvolle Cache-Control-Header. Ich separiere rechenintensive Anwendungen (z. B. API) von Content-Subdomains, damit Caches effizient arbeiten und Lasten sich nicht gegenseitig stören.
Typische Anwendungsfälle effizient umsetzen
Für Inhalte mit eigener Tonalität lege ich blog.meinedomain.de an und führe dort ein schlankes CMS. Einen Shop kapsle ich auf shop.meinedomain.de, damit die Kasse und Produktlogik getrennt laufen. Ein Kundenportal platziere ich auf kunden.meinedomain.de und begrenze den Zugriff über Rollen und IP-Regeln. Kampagnen erhalten aktion.meinedomain.de, damit Tracking, SEO und Content eigenständig messbar bleiben. Entwicklungsstände parke ich auf dev oder staging, damit ich neue Funktionen sicher prüfen kann, bevor ich live gehe.
Für APIs setze ich api.meinedomain.de auf, berücksichtige CORS, Rate-Limits und klare Pfadversionierung (z. B. /v1/). Für interne Tools wähle ich admin- oder intranet-Subdomains und sichere sie stark ab. Für Medien nutze ich media oder cdn, damit Browser parallel laden und Cache-Strategien gezielt greifen. Bei Experimenten und Feature-Previews helfen kurzlebige Subdomains, die ich nach Abschluss wieder lösche, um die Struktur schlank zu halten.
SEO für Subdomains: Best Practices
Ich wähle kurze, sprechende Namen wie blog, shop oder faq und halte die Struktur konsistent. Jede Subdomain bekommt ein eigenes SSL-Zertifikat, eine eigene Sitemap und eine separate Property in der Search Console. Interne Verlinkungen halte ich thematisch sauber, damit Crawler und Nutzer den Zweck jeder Adresse verstehen. Duplicate Content vermeide ich durch klare Canonicals, saubere Redirects und eindeutige Inhalte. Für internationale Inhalte setze ich je Sprache eine Subdomain mit hreflang oder nutze Subfolders, falls die Struktur zentral geführt werden soll.
Ich achte darauf, dass Subdomains wie staging oder dev auf noindex stehen und per Auth geschützt sind. Bei Umzügen zwischen Subdomain und Verzeichnis plane ich Redirects, aktualisiere Sitemaps und kontrolliere Logfiles für Crawl-Fehler. Ich trenne Tracking-Properties pro Subdomain, behalte aber ein Gesamtdashboard, um abteilungsübergreifend Trends zu erkennen. Interne Such- und Filterseiten lasse ich bewusst aus Sitemaps, damit der Index sauber bleibt.
WordPress auf Subdomain installieren
Für ein eigenständiges Projekt lege ich ein eigenes Verzeichnis an, weise die Subdomain darauf zu und installiere WordPress dort frisch. Nutze ich stattdessen eine Multisite, aktiviere ich Subdomains im Netzwerk-Setup und prüfe Wildcard-DNS im Vorfeld. Caching, Bildoptimierung und Updates betreibe ich je Subdomain getrennt, um Fehlerquellen klein zu halten. Wer zur Grundkonfiguration der Domain einen Spickzettel braucht, schaut in diese Anleitung zu IONOS Domain einrichten und ergänzt die Schritte für Subdomains. So bleibt die Wartung planbar und die Performance für jeden Teilbereich jederzeit schlüssig.
Bei Einzelinstallationen achte ich auf eigene Datenbanken oder klare Präfixe, getrennte Upload-Verzeichnisse und unabhängige Cron-Jobs. Ich setze die Site-URL und Home-URL korrekt auf die Subdomain und prüfe, dass keine alten Absolut-Links der Hauptdomain übrig sind. In Multisite-Setups teste ich neue Subdomains zuerst im Netzwerk, bevor ich sie extern freischalte. Für Staging-Instanzen deaktiviere ich Indexierung, erneuere Salts, sperre Suchmaschinen und halte Zugriffsdaten getrennt.
Governance, Benennung und Zusammenarbeit
Ich definiere ein Namensschema und halte es konsequent durch: funktional (api, media, shop), organisatorisch (team, hr) oder geografisch (eu, us), aber nicht gemischt. Änderungen dokumentiere ich dauerhaft: Wer hat wann welchen DNS-Record angelegt, warum und mit welcher TTL. Für größere Teams delegiere ich Subzonen an dedizierte Nameserver und sichere Schreibrechte, damit nicht jeder überall Änderungen vornehmen kann. Ich etabliere Review-Prozesse für DNS, SSL und Redirects, um Ausfälle und SEO-Schäden zu vermeiden.
Tests, Propagation und Diagnose
Ich prüfe die Auflösung aus verschiedenen Netzen und Geräten. Vor der globalen Umstellung teste ich lokal via Hosts-Datei-Zuordnung, um Serverkonfigurationen zu verifizieren. Ich unterscheide, ob ein Fehler aus DNS (NXDOMAIN, falsche IP), Netzwerk (Timeout) oder Anwendung (404/500) stammt. Für SSL vergleiche ich Zertifikatskette, Hostabdeckung und Gültigkeit. Ich beobachte die Zeit bis zur vollständigen Propagation und plane sichtbare Änderungen nicht in Lastspitzen oder kurz vor Kampagnenstarts.
Troubleshooting: Häufige Fehler schnell lösen
Erscheint die neue Adresse nicht, prüfe ich zuerst DNS auf Tippfehler, falsche Record-Typen oder fehlende Ziele. Ich warte realistisch einige Stunden bis hin zu 48 Stunden, weil die weltweite Verbreitung Zeit benötigt. Browser-Cache und lokale DNS-Caches leere ich, um alte Einträge aus dem Weg zu räumen. Für eine Außenprüfung teste ich die Auflösung über mehrere Standorte und kontrolliere, ob A oder CNAME korrekt antworten. Wenn SSL zickt, stoße ich die Zertifikatsausstellung für die Subdomain neu an und prüfe, ob der Host öffentlich erreichbar ist.
Bei 404-Fehlern untersuche ich, ob das Verzeichnis korrekt verknüpft ist und die .htaccess-Regeln greifen. Liefert der Server 403, sind oft Rechte oder Directory-Index betroffen. Liefert er 421/421-Misdirected-Request, stimmt der virtuelle Host nicht zur SNI-Anfrage. Wenn CNAME und A-Record gleichzeitig auf derselben Subdomain existieren, entferne ich Konflikte. Bei DNSSEC-Fehlern prüfe ich Signaturen und Kette; bei CAA-Einträgen passe ich die Aussteller an, damit Zertifikate wieder ausgestellt werden.
Betrieb, Monitoring und Wartung
Ich richte für jede kritische Subdomain Uptime-Checks ein, überwache SSL-Ablaufdaten und behalte Latenz sowie Fehlerquoten im Blick. Deployments laufen skriptgesteuert und reproduzierbar, damit Rollbacks zügig möglich sind. Ich plane Wartungsfenster, zeige Maintenance-Seiten sauber an und halte Redirects für Notfälle bereit. Für Inhalte pflege ich einen getrennten Backup-Plan pro Subdomain, damit Wiederherstellungen zielgenau erfolgen und SLAs eingehalten werden können.
Verwalten und löschen ohne Ausfälle
Im Subdomain-Menü ändere ich das Ziel, wenn ein Dienst umzieht oder ein neues Verzeichnis zum Einsatz kommt. Vor dem Entfernen prüfe ich Abhängigkeiten wie E-Mail-Routing, Weiterleitungen, Tracking und Sitemaps. Ich deaktiviere Weiterleitungen geordnet, sichere Inhalte und setze bei Bedarf vorübergehende 301-Redirects. So bleibt die Nutzerführung intakt, während ich Subdomains bereinige oder zusammenlege. Eine kurze Dokumentation verhindert, dass alte Hosts später versehentlich reaktiviert werden.
Nach Abschaltungen halte ich 301-Weiterleitungen ausreichend lang aufrecht, aktualisiere Verlinkungen und sorge dafür, dass alte URLs in Sitemaps verschwinden. Ich bereinige Security-Gruppen, Zugänge und Cronjobs, damit keine verwaisten Prozesse übrig bleiben. In der Search Console entferne ich obsolet gewordene Properties nur, wenn dauerhaft keine Signale mehr benötigt werden.
Vergleich: IONOS und Alternativen
Bei alltäglichen Projekten reicht die Verwaltung von IONOS für Subdomains, SSL und Standard-DNS völlig aus. Anspruchsvolle Setups mit vielen Records, speziellen Weiterleitungen und externen Diensten profitieren von Anbietern mit sehr breiter DNS-Funktionalität. Wichtig sind klare Oberflächen, Logs für Änderungen und schneller Support, wenn Einträge kritisch sind. Ich wäge Komfort gegen Flexibilität ab und entscheide nach Projektgröße und Teamstruktur. Die folgende Tabelle stellt Kernpunkte kompakt gegenüber, damit die Einordnung leichter fällt.
| Anbieter | Subdomain-Verwaltung | DNS-Flexibilität | Support |
|---|---|---|---|
| webhoster.de | Sehr umfangreich | Exzellent | 24/7 Premium |
| IONOS | Einfach bis mittel | Gut | Guter Standard |
| Mitbewerber X | Mittel | Mittel | Standard |
Kurz zusammengefasst
Ich lege Subdomains bei IONOS zielgerichtet an, setze die passenden Records und kontrolliere die Erreichbarkeit sorgfältig. Eine klare Namensgebung, eigenes SSL und saubere Sitemaps machen Verwaltung und SEO kalkulierbar. Für WordPress trenne ich Projekte konsequent und halte Caching sowie Updates je Subdomain getrennt. Bei Störungen prüfe ich DNS, Cache und Zertifikat, bevor ich Ziele umstelle oder Redirects setze. So bleibt die Struktur verlässlich, die Inhalte laden zügig und jede Subdomain erfüllt ihren Zweck ohne Reibungsverluste.
