Guide

How to host a WordPress site

Installing WordPress on shared hosting, the two settings that break most installs, and the caching step that decides whether your site stays up.

Ben Johnson · last checked 2026-08-04 · 5 min read

WordPress runs a large share of the web, which means two things. Good: every host supports it and every problem has been solved before. Bad: most of the advice you’ll find was written for a different setup than yours.

Here’s what actually matters on shared hosting.

What WordPress needs

Three things, and every shared host has all of them:

• PHP — version 8.1 or newer. Older versions still work but stop getting security fixes.
• A MySQL or MariaDB database — one per site.
• About 50 MB of space for the core files, plus whatever your images take.

That’s it. If you’re not sure what any of that means, what is web hosting covers the basics first.

The fast way: one-click install

Most control panels include Softaculous or a similar installer. Find WordPress, click install, fill in four fields, done in two minutes.

It creates the database, writes the config, and sets up your admin account. For a new site this is the right choice and there’s no prize for doing it by hand.

Two things to get right on that form:

Don’t use admin as your username. Bots try it first on every WordPress site on the internet. Pick anything else.

Install in the root, not a subfolder, unless you specifically want the site at /blog. The installer often defaults to a subdirectory, and moving it later is more annoying than getting it right now.

The manual way

Sometimes you need it — moving a site, or your host has no installer.

1. Download and upload. Get the files from wordpress.org, unzip, and upload the contents of the wordpress folder into your web root. Not the folder itself. Uploading the folder puts your site at /wordpress/ instead of /, which is the single most common first-day mistake.

2. Create the database. In your control panel, make a database and a user, then note four values: database name, username, password, and hostname.

3. Run the installer. Visit your site. WordPress asks for those four values and writes wp-config.php for you.

The setting that breaks most installs

Step 3 is where people get stuck, and it’s nearly always the same field.

Every tutorial says the database host is localhost. On shared hosting it usually isn’t. Your database lives on a different machine, so you need the hostname your host gave you — something like sql203.example.com.

Get it wrong and you see Error establishing a database connection, which is the most common WordPress failure there is.

Your wp-config.php should look like this:

define('DB_NAME',     'u1234_wordpress');
define('DB_USER',     'u1234_wpuser');
define('DB_PASSWORD', 'your-actual-password');
define('DB_HOST',     'sql203.example.com');   // NOT localhost

Watch for trailing spaces inside the quotes. They’re invisible and they break authentication.

Turn on caching before you need it

This is the most important thing on this page.

WordPress builds every page from scratch when someone visits. That takes about two seconds. Your hosting plan lets a limited number of pages build at the same time — around ten on a free plan.

Do the maths: ten slots, two seconds each, means about five visitors per second. The eleventh person arriving at the same moment gets a 508 error instead of your site.

Caching saves a finished copy of each page and hands that out instead. Cached pages skip PHP completely, so they don’t use a slot at all. The same plan then handles roughly ten times the traffic.

Install a caching plugin the day you launch. LiteSpeed Cache if your host runs LiteSpeed, WP Super Cache otherwise. Then check it’s actually working:

curl -sI https://example.com/ | grep -i -E 'x-litespeed-cache|x-cache'

You want to see hit on the second request. Plenty of sites have a cache plugin installed and configured that never actually caches anything.

Things that will bite you on shared hosting

Email won’t send. Contact forms will look like they work and quietly send nothing, because most shared hosts — and every free host — block outbound mail. Use a plugin that sends through an email API instead of PHP’s mail().

Scheduled tasks run on page load. WordPress fakes cron by running scheduled jobs inside a visitor’s request. A backup plugin firing mid-visit eats a process slot for its whole run. Turn it off:

define('DISABLE_WP_CRON', true);

Then trigger wp-cron.php from an external scheduler every 15 minutes.

Plugins are how sites get hacked. Not WordPress itself — outdated plugins. Keep them updated, and delete the ones you’re not using instead of leaving them deactivated. A deactivated plugin’s files are still on disk and still reachable.

Watch the file count. Hosts limit how many files you can store, not just how many gigabytes. WordPress generates six thumbnail sizes per image by default, so a photo gallery hits that limit surprisingly fast.

Before you launch

• Set permalinks to Post name under Settings → Permalinks
• Confirm the site loads over HTTPS with no mixed content warnings
• Install a backup plugin and actually run it once — free hosting doesn’t back anything up for you
• Delete the sample post, page and comment
• Check the site on a phone

What a WordPress site really costs to host

Nothing, if it’s small and cached. A portfolio or a small business site with a few thousand visits a month runs comfortably on a free plan.

It stops being free when you need email to arrive reliably, when downtime starts costing you money, or when you’re hitting resource limits after caching is already on. That last one is the honest signal — it means real traffic, and no amount of configuration fixes it.

Until then, don’t pay for capacity you aren’t using.