Videre til indhold 
Jeg vil vise dig trin for trin, hvordan du opretter en IONOS-underdomæne indstille DNS korrekt og teste adressen ordentligt. Det er sådan, jeg sætter destinationer, SSL og forwarding op, holder strukturen klar og løser typiske fejl uden omveje.
Centrale punkter
Før starten har jeg følgende succesfaktorer i tankerne og arbejder mig igennem dem i rækkefølge, så Underdomæne kører hurtigt og stabilt.
- OpsætningLogin, vælg domæne, navngiv underdomæne
- DNSSæt A, AAAA eller CNAME record korrekt
- SSLAktivér certifikat pr. underdomæne
- SEOSitemaps, klar struktur, intet duplikatindhold
- Test: Vent på udbredelse, tjek målet
Jeg har klare navne, rene DNS-poster og en gyldig SSL i fokus. Det giver mig mulighed for klart at afgrænse tjenester, tests og liveoptræden. Jeg dokumenterer alle ændringer, så jeg kan tilpasse mig hurtigere senere. Jeg planlægger underdomænestrukturen på en sådan måde, at senere udvidelser er nemme. Jeg tjekker tilgængeligheden flere steder, før jeg aktivt promoverer indhold.
Hvad er et subdomæne? Kort forklaret
Et subdomæne udvider hoveddomænet med et foranstillet værtsnavn som f.eks. blog. Det giver mig mulighed for at adskille indhold, tjenester eller teams teknisk og organisatorisk uden at skulle købe et nyt domæne. Eksempler er blog.meinedomain.de, shop.meinedomain.de eller dev.meinedomain.de til test. Ideen: Jeg indkapsler funktioner og kan styre mål, SSL og evaluering uafhængigt af hinanden. Hvis du gerne vil læse om vilkår og muligheder i en kondenseret form, finder du et resumé i dette Definition af kort subdomæne yderligere grundlæggende viden.
Oprettelse af et IONOS-underdomæne: trin for trin
Jeg logger ind på min kundekonto og åbner Domæner & SSL, så vælger jeg den relevante Domæne fra. I underdomæneområdet klikker jeg på Opret underdomæne og indtaster et kort navn som f.eks. blog, butik eller kunde. Jeg angiver enten webmappen på hovedsiden eller en separat mappe til en selvstændig applikation som mål. For eksterne tjenester indstiller jeg et CNAME eller en A-Record til måladressen i DNS-indstillingerne i stedet for et mappemål. Når jeg har gemt, venter jeg på DNS-udbredelsen, tester underdomænet i browseren og tjekker status og SSL i oversigten.
Med IONOS bruger jeg disse måltyper afhængigt af formålet: 1) Webspace-bibliotek til eget indhold, 2) Videresendelse (HTTP/HTTPS) til en anden URL, 3) App- eller webstedslink, hvis der er forbindelse til et byggesæt/en butik, 4) Rent DNS-baseret, hvis der er tale om en ekstern tjeneste. Jeg holder stistrukturen og autorisationer i webrummet konsistente, så implementeringer forbliver reproducerbare. Jeg aktiverer specifikt adgangsbeskyttelse for staging-instanser, så søgemaskiner og brugere ikke ved et uheld lander på dem.
Indstil DNS-destinationer og -records korrekt
Til webindhold linker jeg normalt underdomænet via A-Record til en IPv4-adresse eller via AAAA-record til en IPv6-adresse. Hvis målservicen kører eksternt, sætter jeg ofte en CNAME, der peger på udbyderens host. En fornuftig TTL-værdi er vigtig, så ændringer træder hurtigt i kraft, og efterfølgende ændringer ikke tager en evighed. I DNS-indstillingerne tjekker jeg, om værtsnavn, recordtype og destination stemmer overens. Hvis du vil læse om trinsekvenser i kompakt form, kan du bruge guiden til DNS-indstillinger for IONOS som en påmindelse.
Jeg planlægger TTL-strategien: I faser med mange ændringer sætter jeg en lavere TTL (f.eks. 300-900 sekunder), efter stabilisering øger jeg den igen for at bruge caching. A og AAAA skal pege på det samme system parallelt, ellers vil der være forskellig adfærd afhængigt af klienten. Jeg undgår CNAME'er, når jeg har brug for detaljeret kontrol over A/AAAA eller ønsker at minimere ventetiden. Hvis der bruges et CDN eller en reverse proxy, peger jeg subdomænet til udbyderen via CNAME og dokumenterer de oprindelige IP'er internt.
Ved komplekse opsætninger uddelegerer jeg underzoner: Jeg sætter NS-poster for f.eks. dev.mydomain.com til andre navneservere, hvis et team administrerer udviklingsmiljøet uafhængigt. Jeg kontrollerer, at der ikke er nogen dobbelt autoritet (ingen konkurrerende poster i den overordnede zone). Jeg er også opmærksom på CAA-poster i hovedzonen, hvis certifikatudstedelsen er begrænset; subdomænet arver disse regler.
Sæt omdirigeringer korrekt op
Jeg skelner klart mellem 301 (permanent), 302/307 (midlertidig) og 308 (permanent, behold metoden). For subdomæner, der kun skal omdirigeres, bruger jeg en omdirigering på serversiden og lader stier og forespørgselsstrenge passere uændret, hvis det er muligt. Jeg undgår maskerede omdirigeringer, fordi de gør SSL, SEO og sikkerhed sværere. Når jeg flytter, planlægger jeg omdirigeringsmatricer: subdomænekilder, mål-URL'er, statuskoder, runtime. Jeg holder kæden flad (maksimalt et hop) for ikke at belaste performance og crawling-budget.
Wildcard-underdomæner og FTP-adgang
Hvis jeg router mange underdomæner dynamisk, sætter jeg en Wildcard som *.mydomain.com og pege dem på et standardmål. På den måde ender selv hosts, der endnu ikke er oprettet, på en meningsfuld side eller et catch-all-projekt. Til FTP-adgang kan jeg godt lide at bruge ftp.mydomain.com og gemme et CNAME på den tekniske serveradresse, så værktøjer nemt kan genkende værten. Denne konvention letter teamarbejdet og dokumenterer intentioner i værtsnavnet. Jeg holder også navne som dev, staging eller test konsekvente for klart at adskille teststatusser.
For wildcards er jeg opmærksom på SSL: Afhængigt af taksten og valideringsmetoden kræves der et wildcard-certifikat, ellers vil HTTPS-forbindelsen mislykkes. Jeg tjekker, om visse værter skal udelukkes, f.eks. hvis shop.mydomain.com peger på en ekstern udbyder. Wildcards er stærke, men jeg bruger dem specifikt for at undgå utilsigtede overlapninger mellem hardcodede hosts og catch-all.
Brug e-mail på underdomæner fornuftigt
Hvis jeg har brug for mine egne postkasser til et subdomæne (f.eks. support.mydomain.com), opretter jeg dedikerede MX-poster. Hvis der sendes tjenester fra et subdomæne (f.eks. nyhedsbrev.mydomain.com), tilføjer jeg SPF-poster og opsætter DKIM/DMARC på samme måde som for hoveddomænet. Det holder leveringsevnen stabil, og jeg adskiller afsenderidentiteter korrekt. Jeg undgår at bruge produktive websubdomæner til e-mail på samme tid, så jeg kan indkapsle tjenester rent og udelukke konflikter med DNS-poster.
Sikkerhed og adgangsbeskyttelse
Jeg skifter SSL konsekvent aktiv for hvert underdomæne og omdirigerer automatisk HTTP til HTTPS. For interne miljøer indstiller jeg også grundlæggende auth, IP-restriktioner eller VPN-adgang for at forhindre søgemaskiner og uautoriseret adgang. Jeg tjekker blandet indhold, HSTS og moderne cipher suites for at undgå browseradvarsler. For API'er gemmer jeg CORS-regler pr. underdomæne, så frontends har kontrolleret adgang. Hvor det giver mening, isolerer jeg sessioner og cookies pr. host for at minimere risici fra udbredte cookiedomæner.
Ydeevne, caching og CDN
Jeg beslutter for hvert underdomæne, om et CDN eller en reverse proxy giver merværdi: statisk indhold, international rækkevidde, DDoS-beskyttelse. For aktive cacher planlægger jeg rensningsstrategier og versionering (filnavne med hash), så implementeringer går rent igennem uden besværlige browseropdateringer. På serversiden bruger jeg Etags/Last-Modified og fornuftige cache control headers. Jeg adskiller beregningsintensive applikationer (f.eks. API) fra indholdssubdomæner, så cacher fungerer effektivt, og belastninger ikke forstyrrer hinanden.
Implementer typiske brugsscenarier effektivt
For indhold med sin egen tonalitet opretter jeg blog.meinedomain.de og kører en lean CMS. Jeg indkapsler en shop på shop.mydomain.com, så checkout- og produktlogikken kører separat. Jeg placerer en kundeportal på kunden.meinedomain.de og begrænser adgangen via roller og IP-regler. Kampagner får aktion.meinedomain.de, så sporing, SEO og indhold forbliver uafhængigt målbare. Jeg parkerer udviklingsstatusser på dev eller staging, så jeg sikkert kan teste nye funktioner, før de går live.
Til API'er opretter jeg api.meinedomain.de, tager højde for CORS, hastighedsgrænser og versionering af klare stier (f.eks. /v1/). Til interne værktøjer vælger jeg administrator- eller intranetunderdomæner og sikrer dem kraftigt. Til medier bruger jeg media eller cdn, så browsere indlæses parallelt, og cache-strategier træder i kraft. Kortlivede underdomæner hjælper med eksperimenter og forhåndsvisning af funktioner, som jeg sletter igen, når de er færdige, for at holde strukturen slank.
SEO for underdomæner: bedste praksis
Jeg vælger kort, talende Navne som f.eks. blog, butik eller faq, og hold strukturen konsekvent. Hvert subdomæne har sit eget SSL-certifikat, sit eget sitemap og en separat egenskab i Search Console. Jeg holder interne links tematisk rene, så crawlere og brugere forstår formålet med hver adresse. Jeg undgår duplikatindhold ved at bruge klare kanonikaler, rene omdirigeringer og unikt indhold. For internationalt indhold opretter jeg et underdomæne med hreflang for hvert sprog eller bruger undermapper, hvis strukturen skal administreres centralt.
Jeg sørger for, at underdomæner som staging eller dev er sat til noindex og er beskyttet af auth. Når jeg flytter mellem underdomæner og mapper, planlægger jeg omdirigeringer, opdaterer sitemaps og tjekker logfiler for crawlfejl. Jeg adskiller sporingsegenskaber pr. underdomæne, men beholder et overordnet dashboard for at genkende tendenser på tværs af afdelinger. Jeg udelader bevidst interne søge- og filtersider fra sitemaps, så indekset forbliver rent.
Installer WordPress på et underdomæne
Til et selvstændigt projekt skaber jeg min egen Vejviser tildele underdomænet til det og nyinstallere WordPress der. Hvis jeg i stedet bruger et multisite, aktiverer jeg underdomæner i netværksopsætningen og tjekker wildcard DNS på forhånd. Jeg kører caching, billedoptimering og opdateringer separat for hvert subdomæne for at holde fejlkilderne på et minimum. Hvis du har brug for et snydeark til den grundlæggende konfiguration af domænet, kan du tage et kig på denne guide til Opsæt IONOS-domæne og supplerer trinene for underdomæner. Det betyder, at vedligeholdelse kan planlægges, og at ydeevnen for hvert subdomæne altid forbliver ensartet.
For individuelle installationer sørger jeg for at have mine egne databaser eller klare præfikser, separate uploadmapper og uafhængige cron-jobs. Jeg indstiller webstedets URL og hjemme-URL korrekt på underdomænet og kontrollerer, at der ikke er nogen gamle absolutte links tilbage fra hoveddomænet. I multisite-opsætninger tester jeg først nye underdomæner i netværket, før jeg aktiverer dem eksternt. For staging-instanser deaktiverer jeg indeksering, fornyer salte, blokerer søgemaskiner og holder adgangsdata adskilt.
Styring, navngivning og samarbejde
Jeg definerer et navneskema og holder mig konsekvent til det: funktionelt (api, media, shop), organisatorisk (team, hr) eller geografisk (eu, us), men ikke blandet. Jeg dokumenterer ændringer permanent: Hvem har oprettet hvilken DNS-post hvornår, hvorfor og med hvilken TTL. For større teams uddelegerer jeg underzoner til dedikerede navneservere og sikrer skrivetilladelser, så ikke alle kan foretage ændringer overalt. Jeg etablerer gennemgangsprocesser for DNS, SSL og omdirigeringer for at forhindre udfald og SEO-skader.
Test, udbredelse og diagnose
Jeg tjekker opløsningen fra forskellige netværk og enheder. Før den globale omstilling tester jeg lokalt via mapping af hosts-filer for at verificere serverkonfigurationer. Jeg skelner mellem, om en fejl stammer fra DNS (NXDOMAIN, forkert IP), netværk (timeout) eller applikation (404/500). For SSL sammenligner jeg certifikatkæden, værtsdækningen og gyldigheden. Jeg overvåger tiden indtil fuld udbredelse og planlægger ikke synlige ændringer under spidsbelastninger eller kort før kampagnestart.
Fejlfinding: Løs almindelige fejl hurtigt
Hvis den nye adresse ikke vises, tjekker jeg først DNS for tastefejl, forkerte posttyper eller manglende destinationer. Jeg venter realistisk set et par timer op til 48 timer, fordi global distribution tager tid. Jeg rydder browsercachen og de lokale DNS-cacher for at slippe af med gamle poster. Til en ekstern kontrol tester jeg opløsningen flere steder og tjekker, om A eller CNAME svarer korrekt. Hvis SSL ikke virker, genstarter jeg certifikatudstedelsen for underdomænet og tjekker, om værten er offentligt tilgængelig.
I tilfælde af 404-fejl tjekker jeg, om biblioteket er linket korrekt, og om .htaccess-reglerne er effektive. Hvis serveren returnerer 403, er rettighederne eller katalogindekset ofte påvirket. Hvis den leverer en 421/421 misdirected request, matcher den virtuelle host ikke SNI-anmodningen. Hvis CNAME og A-Record findes samtidig på det samme subdomæne, fjerner jeg konflikter. Ved DNSSEC-fejl kontrollerer jeg signaturerne og kæden; ved CAA-poster justerer jeg udstederne, så certifikaterne udstedes igen.
Drift, overvågning og vedligeholdelse
Jeg opsætter oppetidstjek for hvert kritisk subdomæne, overvåger SSL-udløbsdata og holder øje med latenstid og fejlrater. Implementeringer er scriptstyrede og reproducerbare, så det er muligt at rulle tilbage hurtigt. Jeg planlægger vedligeholdelsesvinduer, viser vedligeholdelsessider tydeligt og holder omdirigeringer klar til nødsituationer. For indhold opretholder jeg en separat backup-plan for hvert subdomæne, så gendannelser kan udføres nøjagtigt, og SLA'er kan overholdes.
Administrer og slet uden fejl
I underdomænemenuen ændrer jeg Målnår en tjeneste flytter, eller en ny mappe tages i brug. Før jeg fjerner dem, tjekker jeg afhængigheder som f.eks. e-mail-routing, omdirigeringer, sporing og sitemaps. Jeg deaktiverer omdirigeringer på en organiseret måde, sikrer indhold og indstiller midlertidige 301-omdirigeringer, hvis det er nødvendigt. Det holder brugervejledningen intakt, mens jeg rydder op eller fusionerer subdomæner. Kort dokumentation forhindrer, at gamle hosts ved et uheld bliver genaktiveret senere.
Efter nedlukninger vedligeholder jeg 301 redirects længe nok, opdaterer links og sørger for, at gamle URL'er forsvinder fra sitemaps. Jeg rydder op i sikkerhedsgrupper, adgange og cron-jobs, så der ikke er forældreløse processer tilbage. I Search Console fjerner jeg kun egenskaber, der er blevet forældede, hvis der ikke længere er brug for signaler på lang sigt.
Sammenligning: IONOS og alternativer
Til hverdagsprojekter kan Administration af IONOS til subdomæner, SSL og standard-DNS. Sofistikerede opsætninger med mange poster, særlige omdirigeringer og eksterne tjenester har gavn af udbydere med meget bred DNS-funktionalitet. Klare grænseflader, logs for ændringer og hurtig support, hvis posterne er kritiske, er vigtige. Jeg vejer bekvemmelighed op mod fleksibilitet og beslutter mig i henhold til projektstørrelse og teamstruktur. Følgende tabel giver en kompakt sammenligning af nøglepunkter for at gøre det lettere at kategorisere.
| Udbyder | Administration af underdomæner | DNS-fleksibilitet | Støtte |
|---|---|---|---|
| webhoster.de | Meget omfattende | Fremragende | 24/7 Premium |
| IONOS | Let til middel | God | God standard |
| Konkurrent X | Medium | Medium | Standard |
Kort opsummeret
Jeg opretter underdomæner hos IONOS på en målrettet måde, indstiller de passende Optegnelser og kontroller omhyggeligt tilgængeligheden. Klar navngivning, dedikeret SSL og rene sitemaps gør administration og SEO beregnelig. Til WordPress adskiller jeg konsekvent projekter og holder caching og opdateringer adskilt for hvert subdomæne. I tilfælde af forstyrrelser tjekker jeg DNS, cache og certifikat, før jeg ændrer mål eller indstiller omdirigeringer. Det sikrer, at strukturen forbliver pålidelig, at indholdet indlæses hurtigt, og at hvert subdomæne opfylder sit formål uden friktionstab.
