Web hosting explained: what happens when someone visits your site

What happens in the second after someone types your address

MDN, Mozilla's reference for web developers, compares the internet to a road. Your visitor's device is a house at one end, the server holding your website is a shop at the other, and every visit follows four steps, each relying on a different part of your setup.

First, the browser looks up your domain in the Domain Name System, the internet's address book, to find the numeric IP address of your server. Second, it sends that server an HTTP request: a short message asking for a page. Third, if all is well, the server replies '200 OK' and sends the page in small chunks called packets, which can travel by different routes and are put back in order when they arrive. Fourth, the browser assembles them into the page your visitor sees.

That first file is rarely the end of it. The HTML that arrives is a set of instructions naming other files, such as style sheets, fonts, scripts and images, and the browser fetches each one in turn. The HTTP Archive found that the median mobile home page in 2025 weighed about 2.6 MB, with images taking up more of it than anything else. Every request for your files has to be answered by your host, promptly, at whatever hour a visitor turns up.

What you are really paying a host for

You could, in theory, run a website from the laptop on your desk. It would need to stay switched on and connected day and night, keep the same internet address, cope with a burst of requests from every visitor and stay patched against attacks. A host takes those jobs on: a server in a data centre with reliable power and a fast connection, web server software to answer requests, storage for your files and, often, tools for HTTPS certificates and email.

Think of it as renting a unit in a managed shopping centre. The landlord keeps the lights on, the doors open and the building secure, but what sits on your shelves is still your responsibility. In hosting terms, the provider looks after the server, while you or your developer look after the website itself: its pages, its software and its updates. Where that line falls varies from plan to plan, so find out before you sign up rather than after something breaks.

Choose hosting by what your site runs

Two sites with similar home pages can need very different hosting. What matters is the work the server has to do each time someone asks for a page.

A static site is a set of finished files that the server hands over exactly as they are. Brochure sites, portfolios and landing pages that change only now and then often work this way. They are quick to serve and have little that can break.

A dynamic site builds each page on request, using an application and a database. WordPress works like this, and the WordPress project recommends PHP 8.3 or later, MySQL 8.0 or later or MariaDB 10.11 or later, and HTTPS support. Online shops, booking systems and members' areas are dynamic too, and they add logins, payments and automatic emails, all of which have to keep working.

Shared hosting, where many sites share one server's resources, suits many small sites. A virtual private server, or VPS, gives you your own allocation of a machine and more control, along with more setting up to do. Managed hosting adds someone who keeps the software updated for you. Choose the simplest option that properly supports what your site runs, and move up when you have a concrete reason. Answer these questions first:

Keep a copy of your site away from your host

In March 2021, fire destroyed one of OVHcloud's data centres in Strasbourg and part of another. According to Netcraft, which surveys web servers, around 3.6 million websites across 464,000 domains went offline, and OVH said no data from the destroyed building was likely to be recoverable.

Some sites were back within hours. Netcraft noted that the UK Government's Vehicle Certification Agency had a new certificate and was online with a UK hosting company by 10am. Recovering that quickly takes two things you can arrange long before anything goes wrong: a recent copy of your site stored somewhere other than your host, and control of your domain, so you can point it at a new server.

Many hosts offer backups, but ask where they are kept and how you would restore one. A copy that sits on the same servers as your live site can disappear along with it.

Check these before you go live

A launch can go wrong in ways no server upgrade will fix: an account nobody can log in to, a contact form sending enquiries to an old inbox, a page nobody tried on a phone.

Pick the one journey that matters most to your business, such as finding a service and sending an enquiry, and test it from start to finish on a phone and on a computer. Send a real enquiry and confirm it arrives, checking the spam folder too. Try it on mobile data as well as Wi-Fi, and in a private browser window where you are not logged in, so you see what a new visitor sees. Once that journey works, you have a baseline for everything you add later.