Installing WordPress by hand takes about ten minutes and consists of four things: create a database, upload the files, connect the two, and run the installer. The one-click installer in cPanel does exactly this for you, so if you only want a working site, use that instead. The one-click install is faster and makes fewer mistakes.
Manual installation is worth knowing anyway. It is how you install into a subdirectory the auto-installer will not touch, how you recover a site whose files exist but whose installation is broken, and it is the only version of this process where you understand what every piece is doing. When something goes wrong later, that understanding is the difference between a fix and a support ticket.
Before you start
You need three things: access to cPanel, a way to move files (File Manager in cPanel is enough, an SFTP client is more comfortable), and a decision about where the site will live. The document root for your main domain is public_html. A site at example.com/blog goes in public_html/blog.
If a site already exists at that location, stop and take a backup first. A manual install into an occupied directory overwrites files, and the installer will happily connect to an existing database and appear to work while having replaced things you wanted.
Step 1: create the database and user
In cPanel, open MySQL Databases. Create a database. The name will be prefixed automatically with your account name, giving something like account_wp01. Write down the full name including the prefix; the prefix is the most commonly forgotten part.
On the same page, create a MySQL user with a strong password. Write that down too, exactly as generated.
Then scroll to Add User To Database, select the user and the database, and grant ALL PRIVILEGES. This step is the one people skip. A user that exists but has not been added to the database produces "Error establishing a database connection" at the end of the install, and the credentials all look correct when you check them, because they are. They simply have no access.
Step 2: upload the WordPress files
Download the current release from wordpress.org. Upload the archive to the directory the site will live in, then extract it there.
Extracting produces a folder named wordpress containing the actual files. If you leave it, your site is at example.com/wordpress, which is almost never what you want. Move the contents of that folder up one level so wp-admin, wp-content, wp-includes and index.php sit directly in your target directory, then delete the now-empty wordpress folder and the archive.
Extracting on the server is much faster than uploading several thousand files individually over SFTP, and it avoids the transfers that silently drop a file or two.
Step 3: create wp-config.php
In the directory you just filled, find wp-config-sample.php and copy it to wp-config.php. Copy it (do not rename it) so the sample remains if you need to start over.
Edit the new file and fill in the three values from step 1:
define( 'DB_NAME', 'account_wp01' ); define( 'DB_USER', 'account_wpuser' ); define( 'DB_PASSWORD', 'the password you saved' ); define( 'DB_HOST', 'localhost' );
DB_HOST stays localhost on Ahosting. Include the account prefix on both the database name and the user name.
Next, replace the block of security keys. The sample file contains placeholder text with a comment pointing at the generator on wordpress.org. Open that URL, copy the whole generated block, and paste it over the placeholder block. These keys encrypt session cookies; leaving the placeholders in place is a real weakness, and it takes ten seconds to avoid.
Optionally change the table prefix from wp_ to something else. This is a mild obstacle to automated attacks, not a security control, but it must be done now, because changing it after installation means renaming tables and editing stored values by hand.
$table_prefix = 'wp_';
Save the file. Watch for a stray space before the opening <?php or after the closing tag; either produces a "headers already sent" warning that looks far more alarming than it is.
Step 4: run the installer
Load the site in a browser. If the files are in place and wp-config.php is correct, WordPress shows the setup form.
Choose the site title, then create the administrator account. Do not use admin as the username. It is the first guess of every automated login attempt, and choosing anything else removes half the value of those attacks for free. Use a long unique password and record it in a password manager before clicking install.
The email address matters: it is where password resets and critical update notices go. Use one you actually read.
Submit the form. WordPress creates its tables and shows a login link. The install is done.
Immediately after installing
Three things are worth doing before you forget.
Set permalinks. Open Settings then Permalinks and choose Post name. Doing this now avoids changing URLs after pages have been indexed.
Enable HTTPS. Ahosting includes a free SSL certificate; once it is active, set both addresses to https://. Setting up an SSL certificate in WordPress explains the mixed-content cleanup that follows.
Turn on automatic updates for plugins, themes and minor core releases. On a fresh install this is a thirty-second job; on a neglected site it is the reason the site gets compromised. Securing WordPress against vulnerabilities explains why this outranks every other hardening step.
When it does not work
Error establishing a database connection. The credentials do not match, or the user was never added to the database with privileges. Re-check the account prefix on both names before anything else.
The setup form never appears and you get a directory listing. The files are one level too deep; the wordpress folder was never flattened.
A blank white page. Usually a typo in wp-config.php. Restore your copy of the sample and fill it in again rather than hunting for the character.
The installer says WordPress is already installed. The database already has WordPress tables in it, from an earlier attempt. Either use a genuinely empty database, or drop the existing tables if you are certain you do not need them.
If a page loads but errors in some other way, fixing common WordPress errors starts with turning on the debug log, which will name the file responsible instead of leaving you guessing.