Skip to content 
I will show you step by step how to create a IONOS subdomain set DNS correctly and test the address properly. This is how I set up destinations, SSL and forwarding, keep the structure clear and solve typical errors without detours.
Key points
Before the start, I keep the following success factors in mind and work through them in sequence so that the subdomain runs fast and stable.
- SetupLogin, select domain, name subdomain
- DNSSet A, AAAA or CNAME record correctly
- SSLActivate certificate per subdomain
- SEO: Sitemaps, clear structure, no duplicate content
- Tests: Wait for propagation, check target
I keep clear names, clean DNS entries and a valid DNS for every project. SSL in focus. This allows me to clearly delineate services, tests and live performances. I document every change so that I can adapt more quickly later. I plan the subdomain structure in such a way that later extensions are easy. I check the accessibility of several locations before actively promoting content.
What is a subdomain? Briefly explained
A subdomain extends the main domain by adding a hostname in front of it, such as blog. This allows me to separate content, services or teams technically and organizationally without having to buy a new domain. Examples are blog.meinedomain.de, store.meinedomain.de or dev.meinedomain.de for tests. The idea: I encapsulate functions and can control targets, SSL and evaluation independently. If you would like to read up on terms and options in a condensed form, you can find a summary in this short subdomain definition additional basic knowledge.
Creating an IONOS subdomain: step-by-step
I log in to my customer account and open Domains & SSL, then I select the appropriate Domain from. In the subdomain area, I click on Create subdomain and enter a short name such as blog, store or customer. I specify either the web directory of the main site or a separate folder for a standalone application as the target. For external services, I set a CNAME or A-Record to the target address in the DNS settings instead of a folder target. After saving, I wait for the DNS propagation, test the subdomain in the browser and check the status and SSL in the overview.
With IONOS, I use these target types depending on the purpose: 1) Webspace directory for my own content, 2) Forwarding (HTTP/HTTPS) to another URL, 3) App or site link if a construction kit/shop is connected, 4) Purely DNS-based if an external service is addressed. I keep the path structure and authorizations in the web space consistent so that deployments remain reproducible. I specifically activate access protection for staging instances so that search engines and users do not accidentally land on them.
Set DNS destinations and records correctly
For web content, I usually link the subdomain via A-Record to an IPv4 address or via AAAA record to an IPv6 address. If the target service runs externally, I often set a CNAME that points to the provider's host. A sensible TTL value is important so that changes take effect quickly and subsequent changes don't take forever. I check in the DNS settings whether the host name, record type and destination match exactly. If you want to read up on step sequences in compact form, use the guide to DNS settings for IONOS as a reminder.
I plan the TTL strategy: In phases with many changes I set a lower TTL (for example 300-900 seconds), after stabilization I increase it again to use caching. A and AAAA should point to the same system in parallel, otherwise there will be different behavior depending on the client. I avoid CNAMEs where I need granular control over A/AAAA or want to keep latency to a minimum. If a CDN or reverse proxy is used, I point the subdomain to the provider via CNAME and document the original IPs internally.
For complex setups, I delegate subzones: I set NS records for e.g. dev.mydomain.com to other nameservers if a team manages the development environment independently. I check that there is no duplicate authority (no competing records in the superordinate zone). I also pay attention to CAA records in the main zone if certificate issuance is restricted; the subdomain inherits these rules.
Set up redirects correctly
I make a clear distinction between 301 (permanent), 302/307 (temporary) and 308 (permanent, retain method). For subdomains that should only redirect, I use a server-side redirect and let paths and query strings pass through unchanged if possible. I avoid masked redirects because they make SSL, SEO and security more difficult. When moving, I plan redirect matrices: subdomain sources, target URLs, status codes, runtime. I keep the chain flat (maximum one hop) so as not to burden performance and crawling budget.
Wildcard subdomains and FTP access
If I route many subdomains dynamically, I set a Wildcard like *.mydomain.com and point them to a standard target. This way, even hosts that have not yet been created end up on a meaningful page or a catch-all project. For FTP access, I like to use ftp.mydomain.com and store a CNAME on the technical server address so that tools can easily recognize the host. This convention facilitates teamwork and documents intentions in the host name. I also keep names such as dev, staging or test consistent in order to clearly separate test statuses.
For wildcards, I pay attention to SSL: Depending on the tariff and validation method, a wildcard certificate is required, otherwise the HTTPS connection will fail. I check whether certain hosts should be excluded, for example if store.mydomain.com points to an external provider. Wildcards are powerful, but I use them specifically to avoid unintentional overlaps between hardcoded hosts and catch-all.
Making sensible use of e-mail on subdomains
If I need my own mailboxes for a subdomain (e.g. support.mydomain.com), I set up dedicated MX records. If services are sent from a subdomain (e.g. newsletter.mydomain.com), I add SPF records and set up DKIM/DMARC in the same way as for the main domain. This keeps deliverability stable and I separate sender identities properly. I avoid using productive web subdomains for e-mail at the same time so that I can encapsulate services cleanly and rule out conflicts with DNS records.
Security and access protection
I switch SSL consistently active for each subdomain and automatically redirect HTTP to HTTPS. For internal environments, I also set basic auth, IP restrictions or VPN access to prevent search engines and unauthorized access. I check mixed content, HSTS and modern cipher suites to avoid browser warnings. For APIs, I store CORS rules per subdomain so that frontends have controlled access. Where it makes sense, I isolate sessions and cookies per host to reduce risks from widely used cookie domains.
Performance, caching and CDN
I decide for each subdomain whether a CDN or reverse proxy offers added value: static content, international reach, DDoS protection. For active caches, I plan purge strategies and versioning (file names with hash) so that deployments go live cleanly without hard browser refreshes. On the server side, I use Etags/Last-Modified and sensible cache control headers. I separate compute-intensive applications (e.g. API) from content subdomains so that caches work efficiently and loads do not interfere with each other.
Efficiently implement typical use cases
For content with its own tonality, I create blog.meinedomain.de and run a lean CMS. I encapsulate a store on store.mydomain.com so that the checkout and product logic run separately. I place a customer portal on kunden.meinedomain.de and restrict access via roles and IP rules. Campaigns are given aktion.meinedomain.de so that tracking, SEO and content remain independently measurable. I park development statuses on dev or staging so that I can safely test new functions before going live.
For APIs, I set up api.meinedomain.de, take CORS, rate limits and clear path versioning (e.g. /v1/) into account. For internal tools, I choose admin or intranet subdomains and secure them strongly. For media, I use media or cdn so that browsers load in parallel and cache strategies take effect. Short-lived subdomains help with experiments and feature previews, which I delete again after completion to keep the structure lean.
SEO for subdomains: best practices
I choose short, speaking Names such as blog, store or faq and keep the structure consistent. Each subdomain gets its own SSL certificate, its own sitemap and a separate property in the Search Console. I keep internal links thematically clean so that crawlers and users understand the purpose of each address. I avoid duplicate content by using clear canonicals, clean redirects and unique content. For international content, I set a subdomain with hreflang for each language or use subfolders if the structure is to be managed centrally.
I make sure that subdomains such as staging or dev are set to noindex and are protected by auth. When moving between subdomains and directories, I plan redirects, update sitemaps and check log files for crawl errors. I separate tracking properties per subdomain, but keep an overall dashboard to identify trends across departments. I deliberately leave internal search and filter pages out of sitemaps to keep the index clean.
Install WordPress on a subdomain
For an independent project, I create my own Directory assign the subdomain to it and freshly install WordPress there. If I use a multisite instead, I activate subdomains in the network setup and check wildcard DNS in advance. I run caching, image optimization and updates separately for each subdomain to keep sources of error to a minimum. If you need a cheat sheet for the basic configuration of the domain, take a look at this guide to Set up IONOS domain and supplements the steps for subdomains. This means that maintenance can be planned and the performance for each subdomain remains consistent at all times.
For individual installations, I make sure I have my own databases or clear prefixes, separate upload directories and independent cron jobs. I set the site URL and home URL correctly on the subdomain and check that there are no old absolute links left from the main domain. In multisite setups, I first test new subdomains in the network before I activate them externally. For staging instances, I deactivate indexing, renew salts, block search engines and keep access data separate.
Governance, designation and cooperation
I define a naming scheme and stick to it consistently: functional (api, media, store), organizational (team, hr) or geographical (eu, us), but not mixed. I document changes permanently: who created which DNS record when, why and with which TTL. For larger teams, I delegate subzones to dedicated name servers and secure write permissions so that not everyone can make changes everywhere. I establish review processes for DNS, SSL and redirects to prevent outages and SEO damage.
Tests, propagation and diagnosis
I check the resolution from different networks and devices. Before the global changeover, I test locally via hosts file mapping to verify server configurations. I differentiate whether an error originates from DNS (NXDOMAIN, incorrect IP), network (timeout) or application (404/500). For SSL, I compare the certificate chain, host coverage and validity. I monitor the time until full propagation and do not plan visible changes during peak loads or shortly before campaign launches.
Troubleshooting: Solve common errors quickly
If the new address does not appear, I first check DNS for typos, incorrect record types or missing destinations. I realistically wait a few hours up to 48 hours because global distribution takes time. I clear the browser cache and local DNS caches to get rid of old entries. For an external audit, I test the resolution across multiple locations and check whether A or CNAME is responding correctly. If SSL is acting up, I restart the certificate issuance for the subdomain and check whether the host is publicly accessible.
For 404 errors, I check whether the directory is linked correctly and whether the .htaccess rules are effective. If the server returns 403, the rights or directory index are often affected. If it delivers a 421/421 misdirected request, the virtual host does not match the SNI request. If CNAME and A-Record exist simultaneously on the same subdomain, I remove conflicts. For DNSSEC errors, I check the signatures and chain; for CAA entries, I adjust the issuers so that certificates are issued again.
Operation, monitoring and maintenance
I set up uptime checks for each critical subdomain, monitor SSL expiration data and keep an eye on latency and error rates. Deployments are script-controlled and reproducible so that rollbacks are possible quickly. I plan maintenance windows, display maintenance pages clearly and keep redirects ready for emergencies. For content, I maintain a separate backup plan for each subdomain so that restores can be carried out accurately and SLAs can be met.
Manage and delete without failures
In the subdomain menu I change the Goalwhen a service is moved or a new directory is used. Before removing them, I check dependencies such as email routing, redirects, tracking and sitemaps. I deactivate redirects in an orderly manner, secure content and set temporary 301 redirects if necessary. This keeps the user experience intact while I clean up or merge subdomains. Brief documentation prevents old hosts from being accidentally reactivated later.
After shutdowns, I maintain 301 redirects long enough, update links and ensure that old URLs disappear from sitemaps. I clean up security groups, accesses and cron jobs so that no orphaned processes remain. In the Search Console, I only remove properties that have become obsolete if signals are no longer required in the long term.
Comparison: IONOS and alternatives
For everyday projects, the Administration of IONOS for subdomains, SSL and standard DNS is completely sufficient. Sophisticated setups with many records, special redirects and external services benefit from providers with very broad DNS functionality. Clear interfaces, logs for changes and fast support if entries are critical are important. I weigh up convenience against flexibility and decide according to project size and team structure. The following table provides a compact comparison of the key points to make the classification easier.
| Provider | Subdomain management | DNS flexibility | Support |
|---|---|---|---|
| webhoster.de | Very extensive | Excellent | 24/7 Premium |
| IONOS | Easy to medium | Good | Good standard |
| Competitor X | Medium | Medium | Standard |
Briefly summarized
I create subdomains at IONOS in a targeted manner, set the appropriate Records and carefully control accessibility. Clear naming, dedicated SSL and clean sitemaps make administration and SEO calculable. For WordPress, I consistently separate projects and keep caching and updates separate for each subdomain. In the event of disruptions, I check the DNS, cache and certificate before changing targets or setting redirects. This way, the structure remains reliable, the content loads quickly and each subdomain fulfills its purpose without friction losses.
