IONOS subdomeinen maken en beheren - stap-voor-stap handleiding

Ik laat je stap voor stap zien hoe je een IONOS-subdomein DNS correct instellen en het adres goed testen. Zo stel ik bestemmingen, SSL en forwarding in, houd ik de structuur overzichtelijk en los ik typische fouten zonder omwegen op.

Centrale punten

Voordat ik begin, houd ik de volgende succesfactoren in gedachten en werk ze op volgorde af, zodat de subdomein draait snel en stabiel.

• SetupInloggen, domein selecteren, naam subdomein
• DNSA, AAAA of CNAME record correct instellen
• SSLCertificaat activeren per subdomein
• SEOSitemaps, duidelijke structuur, geen dubbele inhoud
• TestsWachten op voortplanting, doel controleren

Ik houd duidelijke namen, schone DNS-records en een geldige SSL in de focus. Zo kan ik diensten, tests en live-optredens duidelijk afbakenen. Ik documenteer elke verandering zodat ik later sneller aanpassingen kan doen. Ik plan de subdomeinstructuur zo dat latere uitbreidingen eenvoudig zijn. Ik controleer de toegankelijkheid van verschillende locaties voordat ik content actief promoot.

Wat is een subdomein? Kort uitgelegd

Een subdomein breidt het hoofddomein uit met een voorvoegsel hostnaam zoals blog. Hierdoor kan ik inhoud, diensten of teams technisch en organisatorisch scheiden zonder een nieuw domein te hoeven kopen. Voorbeelden zijn blog.meinedomain.de, shop.meinedomain.de of dev.meinedomain.de voor tests. Het idee: ik kapsel functies in en kan doelen, SSL en evaluatie onafhankelijk beheren. Als je de termen en opties in een beknopte vorm wilt lezen, vind je een samenvatting in deze korte subdomein definitie aanvullende basiskennis.

Een IONOS-subdomein aanmaken: stap voor stap

Ik log in op mijn klantenaccount en open Domeinen & SSL, dan selecteer ik de juiste Domein van. In het subdomeingebied klik ik op Subdomein maken en voer ik een korte naam in, zoals blog, shop of klant. Als doel geef ik de webdirectory van de hoofdsite op of een aparte map voor een standalone toepassing. Voor externe services stel ik een CNAME of A-Record in op het doeladres in de DNS-instellingen in plaats van een mappendoel. Na het opslaan wacht ik op de DNS-propagatie, test ik het subdomein in de browser en controleer ik de status en SSL in het overzicht.

Bij IONOS gebruik ik deze doeltypen afhankelijk van het doel: 1) Webspace-directory voor eigen inhoud, 2) Doorsturen (HTTP/HTTPS) naar een andere URL, 3) App- of sitelink als er een bouwpakket/winkel wordt aangesloten, 4) Zuiver DNS-gebaseerd als er een externe service wordt aangesproken. Ik houd de padstructuur en autorisaties in de webruimte consistent zodat implementaties reproduceerbaar blijven. Ik activeer specifiek toegangsbeveiliging voor staging-instanties zodat zoekmachines en gebruikers er niet per ongeluk op terechtkomen.

DNS-bestemmingen en -records correct instellen

Voor webinhoud koppel ik het subdomein meestal via A-Record naar een IPv4-adres of via een AAAA-record naar een IPv6-adres. Als de doelservice extern draait, stel ik vaak een CNAME in die verwijst naar de host van de provider. Een verstandige TTL-waarde is belangrijk zodat veranderingen snel effect hebben en volgende veranderingen niet eeuwig duren. Ik controleer in de DNS-instellingen of de hostnaam, het recordtype en de bestemming precies overeenkomen. Als je de stappenreeksen in compacte vorm wilt nalezen, gebruik dan de handleiding voor DNS-instellingen voor IONOS ter herinnering.

Ik plan de TTL-strategie: in fasen met veel veranderingen stel ik een lagere TTL in (bijvoorbeeld 300-900 seconden), na stabilisatie verhoog ik deze weer om caching te gebruiken. A en AAAA moeten parallel naar hetzelfde systeem wijzen, anders zal er verschillend gedrag zijn afhankelijk van de client. Ik vermijd CNAME's als ik granulaire controle over A/AAAA nodig heb of als ik latentie wil minimaliseren. Als een CDN of reverse proxy wordt gebruikt, wijs ik het subdomein naar de provider via CNAME en documenteer ik de originele IP's intern.

Voor complexe opstellingen delegeer ik subzones: Ik zet NS-records voor bijvoorbeeld dev.mydomain.com op andere nameservers als een team de ontwikkelomgeving onafhankelijk beheert. Ik controleer of er geen dubbele autoriteit is (geen concurrerende records in de superordinate zone). Ik let ook op CAA-records in de hoofdzone als de uitgifte van certificaten beperkt is; het subdomein erft deze regels.

Redirects correct instellen

Ik maak een duidelijk onderscheid tussen 301 (permanent), 302/307 (tijdelijk) en 308 (permanent, methode behouden). Voor subdomeinen die alleen moeten worden omgeleid, gebruik ik een server-side redirect en laat ik paden en query strings ongewijzigd door als dat mogelijk is. Ik vermijd gemaskeerde redirects omdat ze SSL, SEO en beveiliging bemoeilijken. Bij verhuizingen plan ik redirectmatrices: subdomeinbronnen, doel-URL's, statuscodes, runtime. Ik houd de keten vlak (maximaal één hop) om de prestaties en het crawlingbudget niet te belasten.

Wildcard subdomeinen en FTP-toegang

Als ik veel subdomeinen dynamisch routeer, stel ik een Wildcard zoals *.mydomain.com en wijs ze naar een standaard doel. Op deze manier komen zelfs hosts die nog niet zijn aangemaakt op een zinvolle pagina of een catch-all project terecht. Voor FTP-toegang gebruik ik graag ftp.mydomain.com en sla ik een CNAME op bij het technische serveradres zodat tools de host eenvoudig kunnen herkennen. Deze conventie vergemakkelijkt teamwerk en documenteert intenties in de hostnaam. Ik houd ook namen als dev, staging of test consistent om teststatussen duidelijk te scheiden.

Bij wildcards let ik op SSL: afhankelijk van het tarief en de validatiemethode is een wildcardcertificaat vereist, anders mislukt de HTTPS-verbinding. Ik controleer of bepaalde hosts moeten worden uitgesloten, bijvoorbeeld als shop.mydomain.com naar een externe provider verwijst. Wildcards zijn krachtig, maar ik gebruik ze specifiek om onbedoelde overlappingen tussen hardcoded hosts en catch-all te voorkomen.

Gebruik e-mail op subdomeinen verstandig

Als ik mijn eigen mailboxen nodig heb voor een subdomein (bijv. support.mydomain.com), dan stel ik speciale MX-records in. Als diensten worden verzonden vanaf een subdomein (bijv. nieuwsbrief.mijndomein.nl), voeg ik SPF-records toe en stel ik DKIM/DMARC in op dezelfde manier als voor het hoofddomein. Dit houdt de deliverability stabiel en ik scheid afzender-identiteiten op de juiste manier. Ik vermijd het gebruik van productieve websubdomeinen voor e-mail op hetzelfde moment, zodat ik services netjes kan inkapselen en conflicten met DNS-records kan uitsluiten.

Beveiliging en toegangsbeveiliging

Ik schakel in SSL consequent actief voor elk subdomein en leiden HTTP automatisch om naar HTTPS. Voor interne omgevingen stel ik ook basic auth, IP-beperkingen of VPN-toegang in om zoekmachines en ongeautoriseerde toegang te voorkomen. Ik controleer gemengde inhoud, HSTS en moderne cipher suites om browserwaarschuwingen te voorkomen. Voor API's sla ik CORS-regels op per subdomein zodat frontends gecontroleerde toegang hebben. Waar het zinvol is, isoleer ik sessies en cookies per host om risico's van veelgebruikte cookiedomeinen te minimaliseren.

Prestaties, caching en CDN

Ik beslis voor elk subdomein of een CDN of reverse proxy toegevoegde waarde biedt: statische content, internationaal bereik, DDoS-bescherming. Voor actieve caches plan ik zuiveringsstrategieën en versiebeheer (bestandsnamen met hash) zodat implementaties netjes live gaan zonder moeilijke browserverversingen. Aan de serverkant gebruik ik Etags/Last-Modified en verstandige cache control headers. Ik scheid rekenintensieve toepassingen (bijv. API) van inhoudelijke subdomeinen zodat caches efficiënt werken en belastingen elkaar niet hinderen.

Typische use cases efficiënt implementeren

Voor inhoud met een eigen tonaliteit maak ik blog.meinedomain.de en run ik een lean CMS. Ik kapsel een shop in op shop.mydomain.com zodat de kassa- en productlogica afzonderlijk worden uitgevoerd. Ik plaats een klantenportaal op kunden.meinedomain.de en beperk de toegang via rollen en IP-regels. Campagnes krijgen aktion.meinedomain.de zodat tracking, SEO en content onafhankelijk meetbaar blijven. Ontwikkelingsstatussen parkeer ik op dev of staging zodat ik nieuwe functies veilig kan testen voordat ik live ga.

Voor API's stel ik api.meinedomain.de in, houd ik rekening met CORS, snelheidslimieten en versiebeheer op een duidelijk pad (bijv. /v1/). Voor interne tools kies ik admin- of intranetsubdomeinen en beveilig deze sterk. Voor media gebruik ik media of cdn zodat browsers parallel laden en cachestrategieën effect hebben. Subdomeinen met een korte levensduur helpen bij experimenten en previews van functies, die ik na voltooiing weer verwijder om de structuur slank te houden.

SEO voor subdomeinen: best practices

Ik kies voor kort, sprekend Namen zoals blog, shop of faq en houd de structuur consistent. Elk subdomein heeft zijn eigen SSL-certificaat, zijn eigen sitemap en een aparte eigenschap in de Search Console. Ik houd interne links thematisch schoon zodat crawlers en gebruikers het doel van elk adres begrijpen. Ik voorkom dubbele inhoud door duidelijke canonicals, schone redirects en unieke inhoud te gebruiken. Voor internationale content stel ik voor elke taal een subdomein in met hreflang of gebruik ik submappen als de structuur centraal moet worden beheerd.

Ik zorg ervoor dat subdomeinen zoals staging of dev zijn ingesteld op noindex en zijn beveiligd met auth. Als ik van subdomein naar directory verhuis, plan ik redirects, werk ik sitemaps bij en controleer ik logbestanden op crawlfouten. Ik houd afzonderlijke trackingeigenschappen bij per subdomein, maar houd een overkoepelend dashboard bij om trends tussen afdelingen te herkennen. Ik laat interne zoek- en filterpagina's bewust weg uit sitemaps zodat de index schoon blijft.

WordPress installeren op een subdomein

Voor een onafhankelijk project maak ik mijn eigen Directory wijs het subdomein eraan toe en installeer WordPress daar opnieuw. Als ik in plaats daarvan een multisite gebruik, activeer ik subdomeinen in de netwerkinstellingen en controleer ik vooraf wildcard DNS. Ik voer caching, beeldoptimalisatie en updates afzonderlijk uit voor elk subdomein om foutbronnen tot een minimum te beperken. Als je een spiekbriefje nodig hebt voor de basisconfiguratie van het domein, bekijk dan deze gids voor IONOS-domein instellen en vult de stappen voor subdomeinen aan. Dit betekent dat onderhoud gepland kan worden en dat de prestaties voor elk subdomein altijd consistent blijven.

Voor individuele installaties zorg ik ervoor dat ik mijn eigen databases of duidelijke voorvoegsels, aparte uploadmappen en onafhankelijke cronjobs heb. Ik stel de site URL en home URL correct in op het subdomein en controleer of er geen oude absolute links meer zijn van het hoofddomein. In multisite setups test ik nieuwe subdomeinen eerst in het netwerk voordat ik ze extern activeer. Voor staging-instanties deactiveer ik indexering, vernieuw ik salts, blokkeer ik zoekmachines en houd ik toegangsgegevens gescheiden.

Bestuur, naamgeving en samenwerking

Ik definieer een naamgevingsschema en houd me daar consequent aan: functioneel (api, media, shop), organisatorisch (team, hr) of geografisch (eu, us), maar niet gemengd. Ik documenteer veranderingen permanent: wie heeft welk DNS-record wanneer aangemaakt, waarom en met welke TTL. Voor grotere teams delegeer ik subzones naar speciale naamservers en beveilig ik schrijfrechten zodat niet iedereen overal wijzigingen kan aanbrengen. Ik stel controleprocessen in voor DNS, SSL en redirects om uitval en SEO-schade te voorkomen.

Tests, voortplanting en diagnose

Ik controleer de resolutie vanaf verschillende netwerken en apparaten. Voor de globale omschakeling test ik lokaal via hosts file mapping om serverconfiguraties te verifiëren. Ik onderscheid of een fout afkomstig is van DNS (NXDOMAIN, onjuist IP), het netwerk (time-out) of de toepassing (404/500). Voor SSL vergelijk ik de certificaatketen, hostdekking en geldigheid. Ik controleer de tijd tot volledige propagatie en plan geen zichtbare veranderingen tijdens piekbelastingen of kort voor campagnelanceringen.

Problemen oplossen: veelvoorkomende fouten snel oplossen

Als het nieuwe adres niet verschijnt, controleer ik eerst DNS voor typefouten, onjuiste recordtypes of ontbrekende bestemmingen. Ik wacht realistisch gezien een paar uur tot 48 uur omdat wereldwijde distributie tijd kost. Ik wis de browsercache en lokale DNS-caches om oude vermeldingen te verwijderen. Voor een externe controle test ik de resolutie op verschillende locaties en controleer ik of A of CNAME correct reageren. Als SSL niet werkt, start ik het certificaat voor het subdomein opnieuw op en controleer ik of de host publiek toegankelijk is.

In het geval van 404-fouten controleer ik of de directory correct is gekoppeld en of de .htaccess-regels effectief zijn. Als de server 403 terugstuurt, zijn de rechten of de directory-index vaak aangetast. Als het een 421/421 verkeerd omgeleid verzoek levert, komt de virtuele host niet overeen met het SNI-verzoek. Als CNAME en A-Record tegelijkertijd bestaan op hetzelfde subdomein, verwijder ik conflicten. Voor DNSSEC-fouten controleer ik de handtekeningen en keten; voor CAA-vermeldingen pas ik de verstrekkers aan zodat certificaten opnieuw worden uitgegeven.

Bediening, controle en onderhoud

Ik stel uptime-controles in voor elk kritisch subdomein, monitor SSL-vervalgegevens en houd latentie en foutpercentages in de gaten. Deployments zijn scriptgestuurd en reproduceerbaar zodat rollbacks snel mogelijk zijn. Ik plan onderhoudsvensters, geef onderhoudspagina's duidelijk weer en houd redirects klaar voor noodgevallen. Voor content houd ik voor elk subdomein een apart back-upplan bij, zodat restores nauwkeurig kunnen worden uitgevoerd en SLA's kunnen worden gehaald.

Beheren en verwijderen zonder fouten

In het subdomeinmenu verander ik de Doelwanneer een service verhuist of een nieuwe map wordt gebruikt. Voordat ik ze verwijder, controleer ik afhankelijkheden zoals e-mailrouting, redirects, tracking en sitemaps. Ik deactiveer redirects op een georganiseerde manier, beveilig content en stel indien nodig tijdelijke 301-redirects in. Zo blijft de gebruikersbegeleiding intact terwijl ik subdomeinen opschoon of samenvoeg. Korte documentatie voorkomt dat oude hosts later per ongeluk opnieuw worden geactiveerd.

Na shutdowns onderhoud ik 301 redirects lang genoeg, werk ik links bij en zorg ik ervoor dat oude URL's uit sitemaps verdwijnen. Ik ruim beveiligingsgroepen, toegangen en cronjobs op zodat er geen verweesde processen overblijven. In de Search Console verwijder ik alleen verouderde eigenschappen als signalen op de lange termijn niet meer nodig zijn.

Vergelijking: IONOS en alternatieven

Voor alledaagse projecten is de Administratie van IONOS voor subdomeinen, SSL en standaard DNS. Geavanceerde setups met veel records, speciale redirects en externe services hebben baat bij providers met zeer brede DNS-functionaliteit. Duidelijke interfaces, logboeken voor wijzigingen en snelle ondersteuning als de gegevens kritiek zijn, zijn belangrijk. Ik weeg gemak af tegen flexibiliteit en beslis op basis van projectgrootte en teamstructuur. De volgende tabel geeft een compacte vergelijking van de belangrijkste punten om het categoriseren te vergemakkelijken.

Aanbieder	Beheer subdomeinen	DNS-flexibiliteit	Steun
webhoster.de	Zeer uitgebreid	Uitstekend	24/7 Premium
IONOS	Gemakkelijk tot gemiddeld	Goed	Goede standaard
Concurrent X	Medium	Medium	Standaard

Kort samengevat

Ik maak doelgericht subdomeinen aan bij IONOS, stel de juiste Records en de toegankelijkheid zorgvuldig te regelen. Duidelijke naamgeving, dedicated SSL en schone sitemaps maken beheer en SEO berekenbaar. Voor WordPress scheid ik projecten consequent en houd ik caching en updates apart voor elk subdomein. Bij storingen controleer ik de DNS, cache en het certificaat voordat ik doelen wijzig of redirects instel. Dit zorgt ervoor dat de structuur betrouwbaar blijft, de inhoud snel laadt en elk subdomein zijn doel vervult zonder wrijvingsverliezen.