How To Connect A Domain To Your Website

You bought a name, or you already had one sitting at a registrar from a project you abandoned. Somewhere in your host's dashboard is a page telling you to point it at them, and under that, one line of settings and no explanation of what any of it means.

That is where almost every guide stops. Copy this value into that box, wait a while, good luck.

The problem shows up when it does not work, which is most of the time on the first try. With no model of what is happening you cannot tell "I typed it wrong" apart from "this is normal DNS slowness", so you change things at random for two days.

This page is the map instead. What a registrar does compared to a host, the two different ways to connect a domain and when each one is right, what an A record and a CNAME and an ALIAS each do, why the version without www is harder than the version with it, how long propagation genuinely takes, and why a browser says "not secure" for a few minutes after everything starts working.

By the end you should be able to do this at any registrar, with any host, and know which of the two to blame when it breaks.

Registrar, DNS Host, Web Host: Three Different Jobs

A domain is not a thing you move. It is a name in a global directory, and three separate jobs sit behind it. They are often three separate companies, and the single most common reason a change does nothing is that it was made at the wrong one.

You never really own a domain either. You rent the right to use it, in yearly blocks, and the renewal is yours to lose. MDN on what a domain name is

Here is the sentence that saves people a whole afternoon: connecting a name to a site changes only the middle row. The registration does not move. Your files do not move. One directory answer changes, and every browser follows it.

If the words "host" and "site" are still doing a lot of undefined work here, what hosting actually is covers the ground floor, and this page picks up from there.

The Two Ways To Connect A Domain, And When To Use Each

There are exactly two, and every set of instructions you will ever read is one of them.

Option one: change the nameservers. You go to your registrar and replace the two to four nameserver addresses with the ones your host or DNS provider gives you. That hands over the entire address book for the name. Every record for it now lives at the new provider, and the registrar becomes nothing but the renewal bill.

Option two: leave the nameservers alone and add a record. DNS stays where it is. You add one entry that says "this name points at that host", and everything else about the domain, including your email, carries on untouched.

The decision rule I would use:

• Adding a site to a domain that already does something, especially email? Add a record. Do not touch the nameservers.
• Starting fresh with a name that has never pointed anywhere, and your host offers managed DNS? Change the nameservers. Fewer moving parts, and the host can fix its own records later without asking you.
• Do you have MX records, SPF or DKIM entries, or a mail service on the domain? Add a record, unless you are willing to copy every one of those into the new provider first.
• Not sure which company currently holds your DNS? Add the record wherever your nameservers currently point, not wherever you feel like it.

That last one is the trap. Records only count at the provider your nameservers name. Editing a perfect record in a dashboard that is no longer authoritative is the most common failed hour in this whole process, and nothing in either dashboard will tell you.

A Record, CNAME, ALIAS: What Each One Does

A DNS record is a question and an answer. The question is a name, the answer is what to do with it.

The CNAME rule is not a vendor quirk. The DNS specification says a CNAME record is not allowed to coexist with any other data at the same name. RFC 1912 on common DNS operational errors The bare domain must always carry NS and SOA records, so a CNAME can never legally live there. That single line is why the next section exists.

The practical difference between an A record and a CNAME is who has to keep up. An A record is a number you copied once, correct only until your host reorganises. A CNAME delegates the question, so when the host moves, it moves your site with it and you never find out. Given the choice, take the CNAME.

Apex Or www: The Part That Trips Everyone

example.com is the apex, also called the root or the bare or naked domain. www.example.com is a subdomain of it. To DNS they are two unrelated names, and connecting one does absolutely nothing for the other.

That is the source of the classic complaint: the site works with www and not without it, or the other way round. Nothing is broken. You connected one name.

Because a CNAME cannot sit at the apex, you have three real options:

1. Use a provider with ALIAS records or CNAME flattening. It accepts what looks like a CNAME on the bare name, resolves the target itself, and answers with a plain address. Cloudflare, Namecheap, Porkbun and Route 53 all do this.
2. Point the apex at an A record if your host publishes a stable IP for that purpose. Simple, and it is on you to notice if the IP ever changes.
3. Connect www and forward the apex to it. Nearly every registrar includes free domain forwarding. Set the bare name to redirect to https://www.example.com and you are done.

Option three is unglamorous and works everywhere. If your provider has no flattening, take it and move on.

Whichever you choose, pick one as the real address and redirect the other. Two addresses serving identical pages splits your links and confuses search engines, and which one you pick matters far less than being consistent about it from day one.

The Steps, In Order, At Any Registrar

Registrar dashboards get redesigned constantly, so a click path from a two-year-old blog post is worse than none. The shape below has not changed in a decade.

1. Get the target from your host first. It will be either a hostname to CNAME to, or an IP to point an A record at, plus the exact name it expects: www, or the apex, or both. Copy it. Do not retype it.
2. Find out where your DNS actually lives. Look at the nameservers listed on the domain at your registrar. If they belong to the registrar, you edit records there. If they belong to Cloudflare or anyone else, you edit records there instead.
3. Open the record editor. It is called DNS, Advanced DNS, DNS Management, DNS Records or Manage DNS depending on the company. If you cannot find it, search the registrar's own help for "add a CNAME record" rather than following someone else's screenshots.
4. Lower the TTL first if a record already exists. Set it to five minutes, save, and come back an hour later to make the real change. That one step turns a two-day wait into a five-minute one, and almost nobody does it.
5. Add or edit the record. The name field usually wants just the subdomain part, so www, or @ for the apex. Some editors want the whole thing. If a preview shows www.example.com.example.com, that is the doubling mistake and it is very common.
6. Turn off any proxy toggle while you set up. A proxied record hides the real answer and can block the certificate check that has to happen next.
7. Save, then verify from outside. Your own dashboard only shows you what you typed. Use a global DNS checker, or dig www.example.com in a terminal, to see what the rest of the world gets.
8. Tell the host it is ready. Most hosts poll and flip the status themselves. Some need a button pressed.

A concrete version of that, since abstract steps only get you so far. On OxyPages, a domain you own elsewhere is added from the website's Domains page: choose Add Custom Domain, type the name, press Add Domain, and the page shows you exactly one record to create, a CNAME pointing at cname.myoxypages.com with the proxy off. The record is detected automatically, the certificate is issued, and the status moves from Pending Verification to Valid Configuration on its own. Connecting your own name is a paid-plan feature, so check what each plan includes before you buy a name for it.

Every host has its own version of that screen with its own hostname in it. The steps are the same everywhere.

And the limit worth saying out loud: OxyPages does not sell domains or accept incoming registrar transfers. Your domain stays where you bought it and you point its DNS here, which is useless if what you wanted was to consolidate five domains and a mailbox under one login. Netlify, Cloudflare and most cPanel hosts will register or absorb a name for you. If that is the goal, use one of them.

How Long Propagation Really Takes

Propagation is a misleading word. Nothing spreads. Every DNS answer carries a TTL, a number of seconds saying how long anyone may cache it, and your wait is the old answer's TTL running out somewhere between you and the change.

Which gives you three genuinely different waits:

• A brand new record on a name that never had one. Usually seconds to minutes. There is no old answer to expire. The one delay is negative caching, where a resolver remembers that the name did not exist. Your DNS provider's settings decide for how long, and RFC 2308 suggests one to three hours, so do not visit the address before the record exists.
• Changing an existing record. However long the old TTL was, worst case. If it was set to a day, some visitors get the old answer for a day. This is the one you fix by lowering the TTL in advance.
• Changing nameservers. The slowest by far, because the delegation lives at the top-level domain registry and those records commonly carry a two-day TTL. That is exactly where the famous "up to 48 hours" warning comes from, and it applies to this case only.

What you can actually do about it: lower TTLs a day before you move, make the change, and check from outside rather than from your own browser. Your laptop, your router and your ISP all cache separately, and Chrome keeps its own cache on top. A site that "still is not working" for you while it works for everyone else is a cache on your side, and mobile data with wifi off is the fastest way to prove it.

One habit that costs nothing: never delete the old record and add the new one in two separate steps. Edit it in place. Deleting first means every visitor gets a "does not exist" answer in the gap, and that answer gets cached too.

Why Your Site Says Not Secure Right After The Change

Because the certificate cannot exist before the DNS does, and the browser is telling you the truth.

An HTTPS certificate is issued for an exact hostname, and the issuer proves you control that hostname by looking it up in DNS. So the order is fixed: DNS resolves first, the host requests the certificate second, the padlock appears third. In the window between the first and the second, a browser arriving at your new address gets handed a certificate for somebody else's name and shows a full-page warning. That is correct behaviour and it clears itself.

The three real causes, in the order I would check them:

• You are early. Give it a few minutes after the host reports the domain as verified. Most hosts, including any host that issues certificates automatically, request the certificate the moment they see the DNS record.
• You connected a different hostname than the one you typed. A certificate for www.example.com does not cover example.com. Two names, two certificates. Connect both, or redirect one to the other.
• A proxy is in front of it. If your DNS provider is proxying the record, the certificate check may never reach your host. Turn the proxy off until the status is valid.

If the padlock is there but the page still shows a warning, that is a different problem entirely. It is mixed content: your HTML is loading an image, a font or a script over plain http://. Search your files for http:// and make them all https:// or relative paths. how paths inside an HTML file work explains why relative ones are the safer habit anyway.

Free Subdomain Or Your Own Domain?

Every static host gives you a free address on their own domain the moment you publish, something like yourname.somehost.com. It has real HTTPS, it works everywhere, and it costs nothing.

The honest split:

For a draft you are sending to one client, an event page that dies next month, or anything you are still deciding about, the free address is the correct answer and buying a name is a waste. Nobody judges the URL of a thing in progress. what a free subdomain gives you is the short version, and free plans differ mostly in what else they restrict, which where free hosting draws its lines goes through.

For anything commercial, buy the name. The address is the first thing people judge, usually before they read a word of the page.

One trap specific to free subdomains: changing yours normally releases the old one immediately, with no redirect. Anything already printed, linked or turned into a QR code stops working the moment you save. Your own domain is the only address you can move between hosts without breaking every link you have shared.

What A Domain Costs, And What Renewal Really Does

Prices vary enormously by ending, and the first year is frequently a discount that the renewal is not. Check both numbers before you buy. Any decent registrar shows the renewal price on the same screen as the first-year price, and one that hides it has told you something about itself.

Renewal is where domains are actually lost, and it is almost never deliberate. The pattern is always the same: the card on file expired, the reminder went to an address nobody reads any more, and the charge failed quietly a few times before giving up.

What happens next is worth knowing precisely. After the expiry date most registries allow a grace period of roughly 30 days where you can still renew normally. After that the name can be released or auctioned, and a name that had any traffic at all gets bought within minutes. There is no support ticket that undoes it.

So: keep auto-renew on, keep the card current, and use an email address you will still be reading in three years. A name you connect to OxyPages renews at the registrar you bought it from, never here, so that registrar's renewal settings are the ones to check.

When It Does Not Work: The Six Usual Causes

Nearly every failure is one of these, ordered by how often I see them.

The pattern behind four of those six is the same: something is edited in one place and read from another. Before you change a single value, confirm which company is currently answering for your domain.

What To Do Next

The whole job, compressed:

1. Look up your domain's nameservers. That tells you which dashboard is real.
2. Get the exact target from your host: a hostname to CNAME, or an IP for an A record.
3. If a record already exists on that name, drop its TTL and come back in an hour.
4. Add the record, proxy off, and save.
5. Check it from outside with a DNS checker or dig, not from your own browser.
6. Wait for the host to report the domain as valid, then wait a few more minutes for the padlock.
7. Decide which of the apex and www is the real address, and redirect the other one to it.

If you do not have a site to point at yet, that is the step to do first. getting a page online in the first place takes about a minute for a folder of files, and what a static site is and is not tells you whether that is the right shape for the thing you are building. When you have a live address and a name to attach to it, publish your site and attach your own address is the shortest route from one to the other, and the questions that come up most covers the rest.

The thing to hold on to is how small the change really is. You are not moving your website and you are not moving your domain. You are editing one line in a directory so a name has a new answer, then giving the internet time to notice. Everything else here is detail hanging off that one idea.