On this page
What domain configuration means
Every domain has three layers: the registrar where it is bought, the DNS provider that answers where it points, and the server or platform that actually serves it. Domain configuration is making those three agree, so example.com, www.example.com and shop.example.com all go where they should, with one clear canonical version of your site.
It sounds simple, but it is where many launches and migrations go wrong: a missing www record, a redirect loop, or a record deleted to take something offline that leaves visitors seeing “site cannot be reached” for longer than expected because of caching.
Common situations
- Launching a new website or moving a site to a new server or platform.
- Adding subdomains for an app, a help centre, a store or regional versions.
- An e-commerce brand that owns several domains and wants them to redirect to one main site.
- An agency managing client domains spread across different registrars.
- A domain that was set up years ago by someone who has since left, with nobody sure who controls it.
What’s included
- Audit of registrar, nameservers, current records and where each hostname actually points.
- Apex and www records set, with one canonical host and permanent redirects from the others.
- Subdomains mapped to servers, hosted platforms or third-party services.
- Redirects from secondary or legacy domains, preserving paths where it matters.
- TTLs lowered ahead of changes and restored afterwards.
- Checks that SSL covers every hostname in use.
- A written record of registrar, DNS provider, renewal dates and who has access.
How we stage changes
- Record the current state of every relevant DNS record before touching anything.
- Lower TTLs in advance so the change spreads quickly when it happens.
- Prepare the destination: the new server or platform is ready and has certificates before traffic arrives.
- Make the change, then check from several public resolvers and from outside the network.
- Keep the old destination running until traffic has moved, then restore normal TTLs.
Platforms we work with
We work with common registrars and DNS providers, including Cloudflare, AWS Route 53, Google Cloud DNS, Azure DNS, DigitalOcean and hosting-panel DNS such as Hostinger’s. Destinations range from your own VPS running Nginx to hosted platforms and SaaS tools that need verification records.
What affects timeline and cost
Pointing one domain is quick; propagation time depends on the TTLs already set. More work is needed when there are many domains, access to the registrar is unclear, email records must be preserved during a move, or large sets of legacy URLs need redirect mapping for SEO.
Where email lives on the same domain, we treat mail records as the highest-risk part of any change. They are exported and verified before nameservers move, and test messages are sent afterwards to confirm mail still arrives in both directions.
The domain record you receive
Domain problems are often ownership problems in disguise: nobody knows which account holds the domain, when it renews or which email address receives the warnings. Alongside the technical work, we leave you with a clear record so that never happens again.
| Item | What we record |
|---|---|
| Registrar | Which provider holds the domain and which of your accounts owns it |
| Renewal | Expiry date, auto-renew status and the contact email for renewal notices |
| Nameservers | Where DNS is hosted and who can change it |
| Canonical host | The one address your site uses, and which others redirect to it |
| Subdomains | Each subdomain, what it points to and why it exists |
| Third-party links | Services depending on the domain, such as email, payment verification or search console |
We recommend the registrar account belongs to the business, uses a shared role email rather than one person’s inbox, and has two-factor authentication turned on. These small steps prevent the most painful domain problems: expiry, lost access and unauthorised transfers.
Common mistakes
- Changing nameservers and losing email because MX and TXT records were not copied across.
- Leaving both www and non-www live without a redirect, splitting links and search signals.
- Using temporary (302) redirects where permanent (301) ones were meant.
- Letting a domain expire because renewal emails went to a former employee.
Related: DNS Management, SSL Installation and Server Migration. See Cloud & Server Management, the cloud and server guide, or contact us.
Frequently asked questions
How long does a domain change take to work?
It depends on the TTL already on the record. With TTLs lowered in advance, most visitors see the change within minutes; otherwise it can take hours.
Should my site use www or not?
Either works. What matters is choosing one and redirecting the other to it permanently, so there is one canonical address.
Will moving my domain affect email?
Only if mail records are missed. We copy and verify mail records before any nameserver change.
Do I need to transfer my domain to a new registrar?
Usually not. The registrar can stay where it is; we change DNS or nameservers as needed.
How do you handle redirects from an old domain?
We map important old URLs to their new equivalents with permanent redirects, rather than sending everything to the homepage. That keeps bookmarks, links and search visibility working as well as possible.
Talk to us about domain configuration
Domains pointed, redirected and mapped to the right services without downtime.