You Bought the Domain. What Happens Next?

1. Confirm that the right person controls the domain

You bought control of a name. You did not automatically create a website, mailbox or audience. Start in the registrar account used for the purchase and check the domain name, holder or registrant details, contact email, registrar, status and expiry date. Use an address that someone actively monitors. Register.si makes the holder responsible for the accuracy, completeness, currency and integrity of domain information, and describes email as the primary communication channel between the holder, registrar and registry.

If a freelancer, agency or colleague paid for the domain, check that the registered holder is the person or organisation that should ultimately control it. Keep the confirmation email, invoice and domain-management record somewhere the business can access. This is an operational ownership check, not legal clearance for the name.

2. Protect access and make renewal deliberate

Secure the registrar account with a unique password and multi-factor authentication if the provider offers it. Review recovery addresses, delegated users and active sessions where those controls exist, and keep registrar credentials separate from hosting, website and email credentials. These are sensible account-protection measures, but the exact controls and terminology vary by registrar.

For a business-critical name, ask whether the registrar supports domain lock, transfer protection or Registry Lock. Register.si says a domain under Registry Lock cannot undergo configuration changes except renewal; removing the lock requires a written registrar request and registry verification. That adds security but reduces flexibility, so it is better suited to important domains than every temporary experiment.

Enable auto-renewal if it fits your cash-flow and control preferences, then confirm that the payment method will remain valid. Set calendar reminders as well. Register.si says .si domains can be renewed for one to five years and that renewal can be requested after registration and before the end of a 30-day quarantine period. Treat that as a recovery possibility, not a risk-free grace period: registrar terms, notices, fees and operational interruption may still apply.

3. Separate the registrar, DNS, hosting and email

A registrar manages the registration and its relationship with the .si registry. Hosting stores and serves website files or an application. DNS publishes instructions about where a website and other services are located. Email is a separate service that uses DNS records to route and authenticate messages. One company may sell all four functions in one dashboard, but the functions remain different.

Before switching nameservers, confirm that the new DNS provider has every record you still need: website records, mail records, verification records, subdomains and third-party services. Do not assume that changing nameservers will reproduce the old zone automatically. Make the new zone ready first, then switch the delegation.

For .si delegation, Register.si requires at least two nameservers, authoritative responses over UDP and TCP on port 53, consistency between the delegation and the zone, and no open recursive service. Its pre-delegation checks run every 10 minutes during the first eight hours after a nameserver change, hourly from eight to 24 hours, and daily thereafter. Adding or deleting a nameserver resets that schedule.

That schedule is not a universal promise for worldwide visibility. Registry checks, registrar processing, resolver caches and record TTLs are separate layers, so different networks may see a DNS change at different times. DNSSEC can improve the authenticity and integrity of DNS replies, but Register.si warns that expired signatures or a parent-zone mismatch can produce SERVFAIL and make websites or mail unavailable.

4. Connect the website, email and HTTPS separately

Point the chosen hostname—such as the root domain or a www subdomain—to the hosting service using that service’s instructions. Choose a preferred version, configure the intended redirects and serve it over HTTPS with a certificate covering the hostname. Test the result; a purchased name and a working certificate do not automatically mean the site is launch-ready.

Email setup is separate from website setup. Follow the mail provider’s current instructions for MX records and any authentication records it requires, which may include SPF, DKIM and DMARC. The exact records depend on the provider. Test sending and receiving, including a message to a different provider. A website can load normally while email fails because the two systems rely on different DNS records.

Before announcing the site, test the homepage, important links, forms, mobile layout, redirects, HTTPS certificate and any payment or signup flow. Check that staging pages, private dashboards and test content are not accidentally public. These are recommended launch checks, not a claim that every project needs the same stack or notices.

5. Make the launch findable, without expecting instant visibility

Once the site is genuinely ready, verify ownership in Google Search Console, inspect the main URL and submit a sitemap if the site has one. Google describes Search Console as a way to monitor crawling and indexing, and says sitemap submission can help discovery. It does not guarantee crawling, indexing or ranking.

Google’s minimum technical requirements for eligibility include allowing Googlebot to access the page, returning an HTTP 200 response and providing indexable content. Meeting those requirements still does not guarantee indexing. Domain age alone therefore does not guarantee authority, indexing, traffic or ranking; that is a practical inference from Google’s guidance, not a direct ranking rule.

If you later check the registration through RDAP, keep the result separate from purchase availability. Register.si says HTTP 200 indicates that a domain is registered and/or cannot currently be registered, while 404 means the entered domain was not found but does not guarantee that it can be registered. A 400 indicates an invalid request and 429 means access is temporarily restricted. RDAP, registrar availability and checkout are different checks.