Web hosting and domain names: a practical guide
Every website needs two things: a domain name that people type, and hosting where the site's files live. This guide explains the choices in plain terms, with the security steps that keep your site and your domain yours.
Types of hosting
| Type | What you get | Good for |
|---|---|---|
| Static hosting | Serves plain HTML, CSS and images; often free (GitHub Pages, Cloudflare Pages, Netlify) | Personal sites, documentation, small business pages |
| Shared hosting | Space on a server shared with many other sites, with a control panel, PHP and MySQL | Small WordPress sites and blogs on a tight budget |
| Managed hosting | A platform tuned for one application (WordPress, an online shop) with updates and backups handled for you | Businesses without a technical person |
| VPS or cloud server | Your own virtual Linux server with root access | Custom applications, several sites, learning administration |
| Dedicated server | A whole physical machine | Heavy traffic, special hardware or compliance needs |
If you can run Linux, a small VPS costs about as much as good shared hosting and gives you complete control. The price of that control is that patching, backups and security become your job; setting up a LAMP server shows the work involved.
Free or paid?
Free static hosting from the big platforms is excellent and reliable. Free dynamic hosting (PHP and databases) is a different matter: it usually comes with advertising, tight limits, poor performance, no backups and no support, and some providers use your site to show their own ads. For anything you care about, a few euros a month buys reliable hosting with backups and a real support desk.
Linux or Windows hosting?
Choose by the software your site runs, not by the computer you use at home. PHP, WordPress, Python, Node.js, MySQL/MariaDB and PostgreSQL all run best on Linux, which is why most hosting is Linux. Choose Windows hosting only for software that needs it, such as older ASP.NET Framework applications or Microsoft SQL Server; modern .NET runs on Linux too. You can manage a Linux host perfectly well from Windows or a Mac. See Windows vs Linux.
What to check before you buy hosting
- Daily backups that you can restore yourself, kept for at least a week, plus your own off-site copy.
- Free HTTPS certificates (Let's Encrypt) installed automatically.
- Current, supported PHP and database versions.
- SSH or SFTP access, not just plain FTP.
- Where the servers are (closer to your visitors is faster; data protection law may matter).
- Real limits: "unlimited" plans always have a fair-use limit in the small print.
- The renewal price, which is often much higher than the first-year offer.
- How to leave: can you download all files and databases at any time?
Domain names
Choosing and buying a domain
Domains are sold by registrars accredited by ICANN or by the registry of a country code (such as .uk, .de or .bg). Pick a name that is short, easy to spell and to say aloud, and avoid hyphens and numbers that people will forget. Check that the name does not use someone else's trademark.
- Buy the domain in your own name or your company's, with an e-mail address you control, never in the name of your web designer or host.
- Keep your contact details correct: the registrar sends renewal and transfer notices there.
- Turn on auto-renewal and keep a valid payment method. If a domain expires and is not renewed during the grace periods (usually about 30 to 75 days in total), it is often re-registered within seconds of being released by people who buy domains for their traffic.
- You do not need to buy hosting and domain from the same company. Keeping them separate makes it easier to move hosting later.
DNS in five records
| Record | Points | Example |
|---|---|---|
A | name to IPv4 address | example.com. A 203.0.113.10 |
AAAA | name to IPv6 address | example.com. AAAA 2001:db8::10 |
CNAME | name to another name | www.example.com. CNAME example.com. |
MX | where e-mail for the domain goes | example.com. MX 10 mail.example.com. |
TXT | text: SPF, DKIM, DMARC, ownership checks | example.com. TXT "v=spf1 mx -all" |
Check what the world sees with dig: dig +short example.com A, dig example.com MX. Changes can take up to the record's TTL (time to live) to spread.
Transferring a domain to another registrar
- Check that the domain can be moved: generic domains such as .com usually cannot be transferred in the first 60 days after registration or a previous transfer (ICANN has approved shortening this to 30 days; check your registrar's current rules). Country domains have their own rules.
- At the current registrar, unlock the domain and request the transfer authorisation code (EPP or auth code).
- Start the transfer at the new registrar and enter the code. For .com and similar, a year is usually added to the registration.
- Approve the confirmation e-mail if one is sent. Transfers usually complete within five days.
- Copy the DNS records to the new provider before switching name servers, so the site and e-mail keep working.
Protect your domain from hijacking
Whoever controls your domain controls your website and your e-mail, including password-reset e-mails for every other account. Domain hijacking usually happens through the registrar account, not through technical attacks.
- Use a strong, unique password and two-factor authentication on the registrar account.
- Keep the transfer lock on (
clientTransferProhibited); for important domains ask for a registry lock. - Be suspicious of e-mails about "renewal problems" or "domain verification": they are a common phishing trick. Log in to the registrar directly instead of clicking links.
- Watch the public registration data with
whois example.comand know your expiry date. - Enable DNSSEC if your registrar and DNS host support it.
HTTPS
Every site should use HTTPS. Browsers mark plain HTTP sites as "Not secure", and certificates are free from Let's Encrypt. Good hosts install them automatically; on your own server use Certbot. Then redirect all HTTP requests to HTTPS.
E-mail for your domain
Running your own mail server is hard to do well: getting mail delivered to the big providers needs correct SPF, DKIM and DMARC records, a clean IP address and constant attention. Most people are better served by a hosted mail service on their own domain. Whatever you use, publish SPF, DKIM and DMARC records so others cannot easily send mail in your name.
Keep the site safe
- Update the CMS, themes and plugins as soon as updates appear, and remove plugins you do not use.
- Use strong, unique passwords and two-factor login for the admin area and the hosting control panel.
- Keep your own backup of files and database, outside the hosting account.
- Watch for changes you did not make: new admin users, unknown files, spam pages appearing in search results.
Building a WordPress site
WordPress runs about four in ten websites. It needs PHP and a MySQL or MariaDB database, which every Linux host offers.
- Choose hosting: managed WordPress hosting if you want updates and backups handled for you, or a VPS with a LAMP server if you want full control.
- Install WordPress with the host's one-click installer, or download it from wordpress.org into the web root and run the installer in the browser.
- Use a strong, unique admin password and turn on two-factor login.
- Install only the plugins and themes you need, from the official directory or well-known vendors, and keep all of them updated. Abandoned plugins are the most common way WordPress sites are hacked.
- Turn on automatic updates and daily backups of files and database, kept outside the hosting account.
Moving a site to a new host
- A day before, lower the TTL of the domain's DNS records (for example to 300 seconds) so the switch takes effect quickly.
- Copy the files and export the database, then import them on the new host.
- Test the site on the new host before anyone else sees it: add the new address for your domain to your own computer's
/etc/hostsfile, or usecurl --resolve(seecurl). - Switch the DNS records to the new host and check with
digthat the change has spread. - Keep the old hosting for a week, in case something was missed, and check that HTTPS certificates and e-mail work on the new host.