You have hosting, you have a domain, and now you need to install WordPress on it. The honest answer is that you probably will not install anything by hand. Most hosts run the installer for you from their control panel, and what you get is the same site the manual route produces.
So the useful question is which of the three routes is yours, and what none of them set up for you.
One note on what this article asks you to do. Anything living in a file, such as wp-config.php or FTP access, is described here as something to hand to whoever looks after your hosting. The rest you do from two screens: your host’s panel and the WordPress dashboard.
And the part worth planning for. Of everything you do today, the installation is the part that costs least to get wrong: you throw a broken one away and run it again. The decisions around it are the expensive ones. Unless this is a weekend experiment you will delete on Monday, in which case the installation really is the whole job.
Which way to install WordPress is yours?
Three routes exist, and one question sorts them: does your hosting have a control panel with a WordPress auto-installer in it? If it does, that is your route and the one almost everyone should take; the other two are for a bare server and for practice. Without an installer, the work is manual and belongs to whoever manages that server. The practice route runs on localhost, where nobody else can open it.
| Route | What you need | How long it takes | What you end up with | Who does it |
|---|---|---|---|---|
| Installer in your host’s panel | hosting with an installer, a domain pointed at it | minutes | a live site on your domain | you |
| Manual installation | file access, a database, server credentials | a task of its own, not a step | the same live site | your host’s support or your developer |
| Local installation | server software on your own computer | a setup of its own | a site only you can open | a developer |
All three assume the WordPress you install on hosting you control, the one people call WordPress.org. The hosted WordPress.com service is a separate product with its own rules.
That practice route carries a warning: the site is invisible to customers and to Google, and moving it to real hosting later is a separate job.
So when is a manual installation genuinely required? Three cases, and none of them are about how technical you are. Your hosting has no installer, which happens on a bare server. You need a version or a setup the installer does not offer. Or you are moving an existing site.
Outside those three, the manual route produces the same website by a longer path. The guides ranking above this one half admit it: one opens by saying manual installation is unnecessary because the panel does it in a click, then gives over the rest of the page to the manual method.
What you decide before you install
Four things get settled in this half hour, and three of them are unpleasant to change afterwards: whose name the accounts are in, what the hosting has to support, whether the site sits in the root or a subfolder, and whether it goes live at all. None of them are technical, and none of them appear in the installer.
Whose name it is all in. The domain, the hosting account, the analytics, any paid service attached to the site. This sounds like paperwork until the day you need to move the site and discover the domain is registered to a developer you no longer work with. Put every account in your own name and your own email, even when someone else is doing the setup. It takes a minute now and can be close to unfixable later.
What the hosting has to be able to do. The requirements page on WordPress.org currently asks for PHP 8.3 or newer, and for one of the two database engines WordPress runs on, MariaDB 10.11 or MySQL 8.0. It also lists HTTPS as required for every install, which matters in a moment. Your host’s panel shows the PHP version and changes it from a dropdown, so check it before you install: an old version is the usual reason a fresh site behaves strangely.
Root or subfolder. The root means the site opens at yourdomain.com, a subfolder means yourdomain.com/blog. Changing your mind later involves redirects and a pass over your permalinks, so decide now.
The fourth is live or local, covered above. Check one thing alongside it: your domain’s DNS has to point at this hosting before the site answers on it, and that change takes a while to travel.
Worth separating two things that sound alike. Installing WordPress puts the software on your hosting. Building a site on it, with a design and a structure that suit what you sell, starts after this screen.
The install itself, step by step
From the control panel, the whole thing is a form, and the one-click installer does the rest. You tell it which domain to use, what to call the site and who the administrator is, and it builds the database and the configuration for you. The five-minute install the documentation talks about is this screen, and on most panels, cPanel included, it looks much the same.
- Log into your hosting control panel and find the WordPress installer. Hosts label it differently, so look for the logo.
- Point it at your domain, and choose root or subfolder.
- Fill in the form. The site title can be changed later, the administrator username should be anything except
admin, and the password goes into your password manager while you are looking at it. - Use an email address you can actually open, because password recovery goes there and nowhere else.
- Run it, then log in at
yourdomain.com/wp-admin.
That is a working WordPress site. If your host has no installer, or one of the three cases above applies, the same result is produced by hand by someone with file access to the server.
What to ask for
- Ask
- Ask your host’s support or your developer to install WordPress manually: create the database and the database user, set a distinctive table prefix, upload the files to the right directory, generate fresh security keys in
wp-config.php, and set file ownership to your hosting account rather than the web server user. - Caveat
- We cannot see your configuration. Directory layouts and permission models differ between providers, and parts of this may already be handled or may not apply to your plan at all.
- Check
- Your domain opens,
/wp-adminaccepts the credentials they send you, and those credentials are in your name.
What the installer does not set up
The installer makes a database, writes the configuration and creates your administrator account, and that is the entire list. Everything else people assume arrives with a website is absent: an SSL certificate, backups, a decision about updates, somewhere to test a change before visitors see it. Nothing on the screen will tell you any of that is missing.
A certificate. HTTPS sits on the WordPress requirements page as required for every install, and the installer does not set it up. A fresh site answers on http:// and browsers mark it as not secure. Most hosts include a free SSL certificate as a toggle in the panel, so switch it on and check the site opens on https://.
Backups. There are none. Your host may keep copies on its own schedule, for its own purposes. Those belong to the host, on the host’s terms. The more useful question is not whether copies exist but whether anyone has ever restored one.
An update policy. WordPress will offer updates for the core, the theme and every plugin, and somebody has to decide when they go in and who checks the site afterwards. Left alone, the gap between the version running and the current one grows quietly.
A place to try things. Without a staging copy, everything you do happens on the live site, in front of visitors. Plenty of sites run for years like this without incident. The ones that do hit trouble hit it in public, with no copy of yesterday’s version to fall back on.
Two more sit below the waterline. File permissions from an automated install are usually fine, and from a hurried manual one often are not, so ask whoever did the installation to confirm them. And email: WordPress sends password resets through the server, and on plenty of hosts that silently fails. Send yourself a reset now, while you still remember that you have not tested it.
The last one is not technical at all. Domain, hosting, analytics, anything paid: after a few months of setup by different people, these end up spread across several mailboxes, and reassembling them is its own project.
When a site arrives at IntegroFlow for support, the trouble is rarely a single broken thing. Nothing has failed, exactly. Updates were not installed, nobody ever tried restoring the backup, plugins were added on the basis that they solved the problem in front of someone at the time, and a few of those plugins have since been abandoned by their authors.
Two of these are worth doing in the first week and take minutes: turn on the certificate, and put every account into your own name. The rest can wait, as long as someone has decided who it belongs to.
When it goes wrong
Five things go wrong often enough to be worth naming, and every one of them is recoverable without losing anything, because a fresh installation has nothing in it yet. This is the safest week of the site’s life to break something and start over.
The message Already installed means you ran the installer twice. The first run worked, so log in.
An error about connecting to the database means the site cannot reach it. On a panel installation that usually means the installer was interrupted, and the quickest fix is to delete the site and run it again.
If the site loads but /wp-admin does not, the address WordPress thinks it lives at has stopped matching the one you are typing. That happens after a domain change, and your host’s support can correct it.
A white screen after adding a plugin points at the last thing you installed. Ask your host to disable plugins, then add them back one at a time.
And the local site nobody else can see is working exactly as designed: it is a copy on your own machine. The way out of it is real hosting.
Who keeps it running
Installing WordPress is a one-off, and everything in the list above is the opposite: certificates expire, updates keep arriving, plugins fall out of maintenance, and accounts stay in whoever’s name they were opened under. A site needs little attention month to month. It does need somebody who has decided the answers to six questions, so go through them now, while the site is empty and the answers are still obvious:
- What do you own, and is it in your name? Domain, hosting, analytics, anything with a subscription.
- Where does each of those live, and who else has access?
- What updates, on whose schedule, and who checks the site afterwards?
- What is backed up, and has anyone restored from it?
- What would break the site if it disappeared tomorrow? A plugin nobody maintains counts.
- Is there anywhere to test a change first?
Founder
When a project like that comes to us for support, I usually do not start by fixing individual problems. I start by working out what the client actually owns, where everything is, what gets updated and backed up, which dependencies are critical, and how safe it is to change anything at all.
Dmitry Morozan
founder and web developer, IntegroFlow
You can answer all six yourself today. In a year, with content on the site, plugins you have forgotten about and a renewal date you missed, they take considerably longer.
Keeping those answers current is what our team does month to month, and it looks more like routine than rescue.
If you would rather go through the six questions with someone before any of them turn into a problem, a free look at your setup is a reasonable place to start.