Skapa och hantera IONOS-underdomäner - steg-för-steg-guide

Jag kommer att visa dig steg för steg hur du skapar en IONOS underdomän ställa in DNS korrekt och testa adressen på rätt sätt. Så här sätter jag upp destinationer, SSL och forwarding, håller strukturen tydlig och löser typiska fel utan omvägar.

Centrala punkter

Innan start har jag följande framgångsfaktorer i åtanke och arbetar igenom dem i tur och ordning så att Underdomän går snabbt och stabilt.

• InställningLogga in, välj domän, namnge underdomän
• DNSAnge A, AAAA eller CNAME-post korrekt
• SSLAktivera certifikat per underdomän
• SEOSitemaps, tydlig struktur, inget duplicerat innehåll
• Tester: Vänta på spridning, kontrollera målet

Jag håller tydliga namn, rena DNS-poster och en giltig SSL i fokus. På så sätt kan jag tydligt avgränsa tjänster, tester och liveframträdanden. Jag dokumenterar varje förändring så att jag kan anpassa mig snabbare senare. Jag planerar underdomänstrukturen på ett sådant sätt att det är enkelt att göra senare tillägg. Jag kontrollerar tillgängligheten på flera platser innan jag aktivt marknadsför innehåll.

Vad är en underdomän? Kortfattad förklaring

En subdomän utökar huvuddomänen med ett prefixerat värdnamn, t.ex. blogg. Det gör att jag kan separera innehåll, tjänster eller team tekniskt och organisatoriskt utan att behöva köpa en ny domän. Exempel är blog.meinedomain.de, shop.meinedomain.de eller dev.meinedomain.de för tester. Tanken: Jag kapslar in funktioner och kan styra mål, SSL och utvärdering oberoende av varandra. Om du vill läsa om villkor och alternativ i komprimerad form hittar du en sammanfattning i detta definition av kort subdomän ytterligare grundläggande kunskaper.

Skapa en IONOS-underdomän: steg-för-steg

Jag loggar in på mitt kundkonto och öppnar Domäner & SSL, sedan väljer jag lämplig Domän från. I området för underdomän klickar jag på Skapa underdomän och anger ett kort namn som t.ex. blogg, butik eller kund. Jag anger antingen webbkatalogen för huvudwebbplatsen eller en separat mapp för en fristående applikation som mål. För externa tjänster anger jag ett CNAME- eller A-Record till måladressen i DNS-inställningarna i stället för ett mappmål. Efter att ha sparat väntar jag på DNS-utbredningen, testar underdomänen i webbläsaren och kontrollerar status och SSL i översikten.

Med IONOS använder jag dessa måltyper beroende på syftet: 1) Webspace-katalog för eget innehåll, 2) Vidarebefordran (HTTP/HTTPS) till en annan URL, 3) App- eller webbplatslänk om en byggsats/butik ansluts, 4) Rent DNS-baserad om en extern tjänst adresseras. Jag håller sökvägsstrukturen och behörigheterna i webbutrymmet konsekventa så att driftsättningar förblir reproducerbara. Jag aktiverar specifikt åtkomstskydd för staging-instanser så att sökmotorer och användare inte av misstag landar på dem.

Ange DNS-destinationer och -poster korrekt

För webbinnehåll länkar jag vanligtvis underdomänen via A-Record till en IPv4-adress eller via AAAA-post till en IPv6-adress. Om måltjänsten körs externt sätter jag ofta ett CNAME som pekar på leverantörens host. Ett vettigt TTL-värde är viktigt så att ändringar träder i kraft snabbt och efterföljande ändringar inte tar en evighet. Jag kontrollerar i DNS-inställningarna om värdnamn, posttyp och destination stämmer exakt. Om du vill läsa om stegsekvenser i kompakt form kan du använda guiden till DNS-inställningar för IONOS som en påminnelse.

Jag planerar TTL-strategin: I faser med många ändringar ställer jag in en lägre TTL (t.ex. 300-900 sekunder), efter stabilisering ökar jag den igen för att använda cachelagring. A och AAAA ska peka på samma system parallellt, annars blir det olika beteende beroende på klient. Jag undviker CNAME om jag behöver detaljerad kontroll över A/AAAA eller vill minimera latensen. Om ett CDN eller en omvänd proxy används pekar jag subdomänen till leverantören via CNAME och dokumenterar de ursprungliga IP-adresserna internt.

För komplexa konfigurationer delegerar jag subzoner: Jag ställer in NS-poster för t.ex. dev.mydomain.com till andra namnservrar om ett team hanterar utvecklingsmiljön självständigt. Jag kontrollerar att det inte finns någon duplicerad auktoritet (inga konkurrerande poster i den överordnade zonen). Jag är också uppmärksam på CAA-poster i huvudzonen om certifikatutfärdandet är begränsat; underdomänen ärver dessa regler.

Ställ in omdirigeringar på rätt sätt

Jag gör en tydlig åtskillnad mellan 301 (permanent), 302/307 (tillfällig) och 308 (permanent, behåll metoden). För underdomäner som bara ska omdirigeras använder jag en omdirigering på serversidan och låter sökvägar och frågesträngar passera oförändrade om möjligt. Jag undviker maskerade omdirigeringar eftersom de försvårar SSL, SEO och säkerhet. När jag flyttar planerar jag omdirigeringsmatriser: underdomänskällor, målwebbadresser, statuskoder, körtid. Jag håller kedjan platt (högst ett hopp) för att inte belasta prestanda och crawlingbudget.

Underdomäner med jokertecken och FTP-åtkomst

Om jag dirigerar många underdomäner dynamiskt ställer jag in en Joker som *.mydomain.com och peka dem mot ett standardmål. På så sätt hamnar även värdar som ännu inte har skapats på en meningsfull sida eller ett catch-all-projekt. För FTP-åtkomst vill jag använda ftp.mydomain.com och lagra ett CNAME på den tekniska serveradressen så att verktyg lätt kan känna igen värden. Denna konvention underlättar teamarbetet och dokumenterar avsikterna med värdnamnet. Jag håller också namn som dev, staging eller test konsekventa för att tydligt separera teststatusar.

För wildcards är jag uppmärksam på SSL: Beroende på tariff och valideringsmetod krävs ett wildcard-certifikat, annars kommer HTTPS-anslutningen att misslyckas. Jag kontrollerar om vissa värdar ska uteslutas, till exempel om shop.mydomain.com pekar på en extern leverantör. Wildcards är kraftfulla, men jag använder dem specifikt för att undvika oavsiktliga överlappningar mellan hårdkodade värdar och catch-all.

Använd e-post på underdomäner på ett förnuftigt sätt

Om jag behöver egna brevlådor för en subdomän (t.ex. support.mydomain.com) skapar jag särskilda MX-poster. Om tjänster skickas från en underdomän (t.ex. nyhetsbrev.mydomain.com) lägger jag till SPF-poster och konfigurerar DKIM/DMARC på samma sätt som för huvuddomänen. På så sätt hålls leveransbarheten stabil och jag separerar avsändaridentiteterna på rätt sätt. Jag undviker att använda produktiva webbunderdomäner för e-post samtidigt så att jag kan kapsla in tjänsterna på ett snyggt sätt och utesluta konflikter med DNS-poster.

Säkerhet och tillträdesskydd

Jag byter SSL konsekvent aktiva för varje underdomän och omdirigerar automatiskt HTTP till HTTPS. För interna miljöer ställer jag också in grundläggande autentisering, IP-restriktioner eller VPN-åtkomst för att förhindra sökmotorer och obehörig åtkomst. Jag kontrollerar blandat innehåll, HSTS och moderna chiffersviter för att undvika webbläsarvarningar. För API:er lagrar jag CORS-regler per underdomän så att frontends har kontrollerad åtkomst. Där det är rimligt isolerar jag sessioner och cookies per värd för att minimera riskerna med cookie-domäner som används i stor utsträckning.

Prestanda, cachelagring och CDN

Jag bestämmer för varje underdomän om ett CDN eller en omvänd proxy ger mervärde: statiskt innehåll, internationell räckvidd, DDoS-skydd. För aktiva cacheminnen planerar jag strategier för rensning och versionshantering (filnamn med hash) så att driftsättningen kan ske utan att webbläsaren behöver uppdateras. På serversidan använder jag Etags/Last-Modified och förnuftiga cache control-headers. Jag separerar beräkningsintensiva applikationer (t.ex. API) från innehållsunderdomäner så att cacher fungerar effektivt och belastningar inte stör varandra.

Implementera typiska användningsfall på ett effektivt sätt

För innehåll med en egen tonalitet skapar jag blog.meinedomain.de och kör en mager CMS. Jag kapslar in en butik på shop.mydomain.com så att kassan och produktlogiken körs separat. Jag placerar en kundportal på kunden.meinedomain.de och begränsar åtkomsten via roller och IP-regler. Kampanjer får aktion.meinedomain.de så att spårning, SEO och innehåll förblir oberoende mätbara. Jag parkerar utvecklingsstatusar på dev eller staging så att jag på ett säkert sätt kan testa nya funktioner innan jag går live.

För API:er sätter jag upp api.meinedomain.de, tar hänsyn till CORS, hastighetsbegränsningar och versionshantering med tydlig sökväg (t.ex. /v1/). För interna verktyg väljer jag administratörs- eller intranätunderdomäner och säkrar dem starkt. För media använder jag media eller cdn så att webbläsarna laddar parallellt och cache-strategierna får effekt. Kortlivade underdomäner hjälper till med experiment och förhandsvisningar av funktioner, som jag tar bort igen efter slutförandet för att hålla strukturen smal.

SEO för underdomäner: bästa praxis

Jag väljer kort, talande Namn som blogg, butik eller faq och håll strukturen konsekvent. Varje underdomän har sitt eget SSL-certifikat, sin egen webbplatskarta och en separat egenskap i Search Console. Jag håller interna länkar tematiskt rena så att sökrobotar och användare förstår syftet med varje adress. Jag undviker duplicerat innehåll genom att använda tydliga canonicals, rena omdirigeringar och unikt innehåll. För internationellt innehåll skapar jag en underdomän med hreflang för varje språk eller använder undermappar om strukturen ska hanteras centralt.

Jag ser till att underdomäner som staging eller dev är inställda på noindex och skyddas av auth. När jag flyttar mellan underdomäner och kataloger planerar jag omdirigeringar, uppdaterar sitemaps och kontrollerar loggfiler för crawlfel. Jag separerar spårningsegenskaper per underdomän, men behåller en övergripande instrumentpanel för att känna igen trender mellan avdelningar. Jag lämnar medvetet intern sökning och filtersidor utanför sitemaps så att indexet förblir rent.

Installera WordPress på en underdomän

För ett självständigt projekt skapar jag min egen Katalog tilldela subdomänen till den och nyinstallera WordPress där. Om jag istället använder en multisite aktiverar jag subdomäner i nätverksinställningen och kontrollerar DNS med jokertecken i förväg. Jag kör cachelagring, bildoptimering och uppdateringar separat för varje subdomän för att minimera antalet felkällor. Om du behöver en lathund för den grundläggande konfigurationen av domänen kan du ta en titt på den här guiden till Konfigurera IONOS-domän och kompletterar stegen för underdomäner. Detta innebär att underhållet kan planeras och att prestandan för varje subdomän alltid förblir konsekvent.

För enskilda installationer ser jag till att jag har mina egna databaser eller tydliga prefix, separata uppladdningskataloger och oberoende cron-jobb. Jag ställer in webbplats-URL och hem-URL korrekt på underdomänen och kontrollerar att det inte finns några gamla absoluta länkar kvar från huvuddomänen. I multisite-konfigurationer testar jag först nya underdomäner i nätverket innan jag aktiverar dem externt. För staging-instanser avaktiverar jag indexering, förnyar salter, blockerar sökmotorer och håller åtkomstdata åtskilda.

Styrning, namngivning och samarbete

Jag definierar ett namngivningsschema och håller mig konsekvent till det: funktionellt (api, media, shop), organisatoriskt (team, hr) eller geografiskt (eu, us), men inte blandat. Jag dokumenterar ändringar permanent: vem skapade vilken DNS-post när, varför och med vilken TTL. För större team delegerar jag subzoner till dedikerade namnservrar och säkrar skrivbehörigheter så att inte alla kan göra ändringar överallt. Jag upprättar granskningsprocesser för DNS, SSL och omdirigeringar för att förhindra avbrott och SEO-skador.

Tester, spridning och diagnos

Jag kontrollerar upplösningen från olika nätverk och enheter. Före den globala övergången testar jag lokalt via mappning av hosts-filer för att verifiera serverkonfigurationer. Jag skiljer på om ett fel härrör från DNS (NXDOMAIN, felaktig IP), nätverk (timeout) eller applikation (404/500). För SSL jämför jag certifikatkedjan, värdtäckningen och giltigheten. Jag övervakar tiden fram till full spridning och planerar inte synliga förändringar under toppbelastningar eller strax före kampanjlanseringar.

Felsökning: Lös vanliga fel snabbt

Om den nya adressen inte visas kontrollerar jag först DNS för stavfel, felaktiga posttyper eller saknade destinationer. Jag väntar realistiskt sett några timmar upp till 48 timmar eftersom global distribution tar tid. Jag rensar webbläsarens cache och lokala DNS-cacher för att bli av med gamla poster. För en extern kontroll testar jag upplösningen på flera platser och kontrollerar om A eller CNAME svarar korrekt. Om SSL inte fungerar startar jag om certifikatutfärdandet för underdomänen och kontrollerar om värden är allmänt tillgänglig.

När det gäller 404-fel kontrollerar jag om katalogen är länkad på rätt sätt och om .htaccess-reglerna är effektiva. Om servern returnerar 403 påverkas ofta rättigheterna eller katalogindexet. Om den levererar en 421/421 felriktad begäran matchar den virtuella värden inte SNI-begäran. Om CNAME och A-Record finns samtidigt på samma underdomän tar jag bort konflikter. Vid DNSSEC-fel kontrollerar jag signaturerna och kedjan; vid CAA-poster justerar jag utfärdarna så att certifikaten utfärdas på nytt.

Drift, övervakning och underhåll

Jag ställer in upptidskontroller för varje kritisk underdomän, övervakar SSL-utgångsdata och håller ett öga på latens och felfrekvenser. Driftsättningar är skriptstyrda och reproducerbara så att det snabbt går att göra rollbacks. Jag planerar underhållsfönster, visar underhållssidor på ett tydligt sätt och håller omdirigeringar redo för nödsituationer. För innehåll har jag en separat backup-plan för varje subdomän så att återställningar kan utföras korrekt och SLA:er kan uppfyllas.

Hantera och radera utan fel

I menyn för underdomänen ändrar jag Målnär en tjänst flyttas eller en ny katalog används. Innan jag tar bort dem kontrollerar jag beroenden som e-postrouting, omdirigeringar, spårning och sitemaps. Jag avaktiverar omdirigeringar på ett organiserat sätt, säkrar innehåll och ställer in tillfälliga 301-omdirigeringar om det behövs. Detta håller användarvägledningen intakt medan jag städar upp eller slår samman subdomäner. Kortfattad dokumentation förhindrar att gamla värdar av misstag återaktiveras senare.

Efter nedstängningar underhåller jag 301-omdirigeringar tillräckligt länge, uppdaterar länkar och ser till att gamla webbadresser försvinner från sitemaps. Jag rensar upp i säkerhetsgrupper, åtkomster och cron-jobb så att det inte finns några föräldralösa processer kvar. I Search Console tar jag bara bort egenskaper som har blivit föråldrade om signalerna inte längre behövs på lång sikt.

Jämförelse: IONOS och alternativ

För vardagliga projekt används Administration av IONOS för underdomäner, SSL och standard-DNS. Sofistikerade konfigurationer med många poster, speciella omdirigeringar och externa tjänster drar nytta av leverantörer med mycket bred DNS-funktionalitet. Tydliga gränssnitt, loggar för ändringar och snabb support om posterna är kritiska är viktigt. Jag väger bekvämlighet mot flexibilitet och bestämmer mig beroende på projektstorlek och teamstruktur. Följande tabell ger en kompakt jämförelse av viktiga punkter för att göra det lättare att kategorisera.

Leverantör	Hantering av underdomäner	DNS-flexibilitet	Stöd
webhoster.de	Mycket omfattande	Utmärkt	24/7 Premium
IONOS	Lätt till medel	Bra	God standard
Konkurrent X	Medium	Medium	Standard

Kortfattat sammanfattat

Jag skapar underdomäner på IONOS på ett målinriktat sätt, ställer in lämpliga Rekord och kontrollerar noggrant tillgängligheten. Tydlig namngivning, dedikerad SSL och rena sitemaps gör administration och SEO beräkningsbara. För WordPress separerar jag konsekvent projekten och håller cachning och uppdateringar åtskilda för varje subdomän. I händelse av störningar kontrollerar jag DNS, cache och certifikat innan jag ändrar mål eller ställer in omdirigeringar. På så sätt säkerställs att strukturen förblir tillförlitlig, att innehållet laddas snabbt och att varje subdomän uppfyller sitt syfte utan friktionsförluster.