The simplest way to install WordPress is through your hosting installer. Choose a manual installation when you need control over the files and database, or use WP-CLI when you manage a VPS whose stack is already working. All three routes have the same destination: WordPress in the correct document root, connected to a dedicated database, and available over HTTPS. The official WordPress installation guide sets out the core flow: download WordPress, create a database, prepare the configuration, upload the files, and run the installer.
Do not start by copying files. First decide where the site will live, check DNS and HTTPS, and prepare a backup with a specific way back if the domain already serves content. That preparation prevents the most common failures: installing into the wrong directory, overwriting a live site, or exposing credentials.
Choose the right WordPress installation method
Comparison of the three installation routes
| Method | Best when | You need to control | Complexity |
|---|---|---|---|
| Hosting installer | Your plan includes an application installer and you want a guided setup. | Domain, directory, HTTPS, administrator account, backups, and updates. | Low |
| Manual on hosting | The panel has no installer, or you want to decide how the files and database are created and placed. | Document root, secure transfer, database, permissions, and configuration. | Medium |
| VPS with WP-CLI | You already manage the server, and Apache or Nginx, PHP, the database, DNS, and TLS are ready. | The full stack, ownership and permissions, virtual host, firewall, updates, and recovery. | High |
For a first website or a small business, panel-based hosting usually reduces operational work. A VPS provides control, but it does not install or maintain PHP, the web server, database, or certificates for you. If you are still comparing plans, read how to choose web hosting around your project's limits and responsibilities.
Requirements and preparation before installation
Check versions, HTTPS, and panel access
As of August 11, 2026, the official download page offers WordPress 7.0.3. Treat that as a dated checkpoint, not a permanently current version: confirm the stable release again on installation day.
The recommended baseline is PHP 8.3 or newer, MariaDB 10.11 or newer or MySQL 8.0 or newer, plus HTTPS. WordPress may continue to run on legacy software, but an end-of-life release no longer has the maintenance expected from a sound production baseline. Always compare your server with the current official WordPress requirements. Apache and Nginx are both suitable when configured to serve the application and its permalink rules.
- Confirm the exact domain and subdomain, such as
example.comand, if you will use it,www.example.com. - Identify the document root assigned by the panel or virtual host. It may be named
public_html,htdocs, or use a custom path; do not guess. - Make sure you can manage files, databases, DNS, and certificates, or know who owns each task.
- Use SFTP, SSH, or the panel's File Manager. Do not send credentials over unencrypted FTP.
Choose the root or a subdirectory
Install at the root when WordPress should open at https://example.com/. Use a subdirectory only when you intentionally want a URL such as https://example.com/blog/. In a hosting installer, an empty “directory” field usually means the root, but interfaces vary: inspect the destination URL in the summary before confirming. For a manual installation, index.php should sit directly in the chosen document root or subdirectory, not inside one extra folder called wordpress.
Back up the current site and define rollback
If the domain already has a website, associated mail, or a database in use, stop before replacing anything. Keep an independent copy of the current files, export its database, and record the DNS configuration, PHP version, document root, and redirects. Verify that the backup is readable and that you have the credentials needed to restore it. The WordPress backup documentation distinguishes files from the database: you need both for complete site recovery.
Write rollback as an operational sentence: “restore the previous files, import the previous database, reapply the configuration, and return DNS to its former destination.” If you cannot carry out that sentence or do not know how long restoration takes, you do not yet have a rollback plan.
Create a dedicated database and separate accounts
Create a database solely for this site and a user with only the permissions required on that database, not global privileges across the server. Store the database name, user, host, and password in a secrets manager. The official guide covers creating a WordPress database through several panels and clients.
The WordPress administrator is separate from the database account. Choose a non-obvious username—not admin, the domain, or your full email address—a unique password, and an email account you control. Do not share the primary account: create named users and give each person the least-privileged role they need.
Method 1: install WordPress through hosting or DirectAdmin
This route is appropriate when the provider offers an application installer. DirectAdmin does not universally include Softaculous: use it if your plan includes it. Menu labels and field order may differ by provider and panel version.
- Open the correct domain. Sign in to the panel, select the domain, and confirm its document root. If content already exists, complete the backup and rollback plan first.
- Prepare DNS and the certificate. The domain normally needs to point at the hosting service so the certificate can be issued or validated. Some panels let you install before propagation finishes, but that does not make HTTPS complete.
- Find the installer. It may be listed under applications, WordPress Manager, or Softaculous. If it is unavailable, use the manual method; do not download a third-party installer.
- Select protocol, domain, and directory. Choose
https://once the certificate is active. Leave the directory empty for the root only after checking the destination URL; enterblogif you want/blog/. - Configure the site and administrator. Enter the site name, language, email, and a non-obvious administrator account. Generate the password in a manager and do not send it through chat or email.
- Review the database, backups, and updates. The installer may create the database automatically. Make sure it is dedicated, learn where backups are stored, and decide which updates to automate based on your ability to test and recover.
- Read the final summary. Confirm the finished URL and path, and make sure another application will not be overwritten. Retain an operation record without copying passwords into it.
When the process finishes, open the homepage and /wp-admin/ in a private window. If the panel reports success but you see another website, a file listing, or a certificate warning, do not repeat the installation. Check the document root, DNS, and HTTPS using the diagnostic section below.
Method 2: install WordPress manually on web hosting
- Download WordPress from the official website. Get the package from wordpress.org; avoid mirrors, bundled “packs,” or installers hosted by third parties.
- Upload the package securely. Use the File Manager or SFTP and place it in a temporary directory within your account. Extracting on the server is usually more reliable than uploading thousands of individual files.
- Place the contents in the document root. Move the contents of the extracted directory, not necessarily the container directory itself. Check that
wp-admin,wp-content,wp-includes, andindex.phpare in the intended destination. - Create the dedicated database and user. Use the panel's MySQL or MariaDB section and grant access only to that database. Copy the values from your secrets manager when the installer asks for them.
- Open the final URL over HTTPS. The wizard asks for language, database details, site title, administrator account, and email. If the server can write
wp-config.php, it will create the file. Otherwise, follow the wizard's own instruction and remove any temporary copy that contains secrets. - Remove the archive. After verifying the installation, delete the package and extraction duplicates left under a public path.
Do not fix a write error by assigning 777 permissions. Find out which user runs PHP and which ownership model your hosting service requires. The official hardening guide recommends limiting write access and protecting sensitive files; the exact owner and permission model depends on the server configuration.
Method 3: install WordPress on a VPS with WP-CLI
This route does not install the VPS stack. Continue only after the Apache or Nginx virtual host, PHP and the required extensions, MariaDB or MySQL, DNS, TLS, document root, file ownership, and a working WP-CLI installation are ready. The dedicated database and user must also exist. If any component is missing, finish preparing the server first or use panel-based hosting.
Connect over SSH and run WP-CLI as the site owner, not as root. Replace the path and example values with those from your virtual host. The official wp core download command retrieves the WordPress files:
cd /var/www/example.com/public
wp core download --locale=en_USConfirm that the download landed in the empty document root with the expected owner. Then create wp-config.php. wp config create can prompt for the database password, keeping the secret out of the command arguments and shell history:
Install WordPress on web hosting that's ready to go
Choose Web Hosting when you want a panel-guided setup without operating the entire server stack yourself.
wp config create --dbname=wp_example --dbuser=wp_example --dbhost=localhost --prompt=dbpassIf the connection fails, do not add the password directly to the command line. Check the name, user, host, permissions, and whether the database service listens where you expect. Once configuration connects successfully, run the installation. The wp core install command can also request the administrator password interactively:
wp core install --url='https://example.com' --title='Example site' --admin_user='site_manager' --admin_email='[email protected]' --locale=en_US --prompt=admin_passwordReplace every example value. Next, confirm that home and siteurl use the final domain and https://, PHP serves the homepage, and the web server applies the permalink rules. Never paste a private key, password, or token into shell history, tickets, or screenshots.
Configure DNS and HTTPS without a half-live launch
The A record should direct the domain to the hosting service or VPS IPv4 address. If you publish an AAAA record, its IPv6 address must also reach the correct server. Configure www for the variant you chose, and avoid leaving the two names on different destinations by accident. For a refresher on records, propagation, and TTL, see how DNS works.
Check resolution from more than one network and wait for the applicable TTL before treating a stale DNS answer as a WordPress failure. During a migration, lower the TTL in advance when you have authority to do so. This does not clear existing caches, but it can shorten later changes.
Issue the certificate for every name that will serve the site and validate HTTPS before forcing redirects. Then set the WordPress URLs to https:// and apply one consistent HTTP-to-HTTPS redirect. The official WordPress HTTPS documentation explains why the server and application URLs must agree. Enabling a redirect before the certificate or proxy is configured correctly can produce a loop or lock you out of the dashboard.
Before launch, keep any staging environment access-controlled and out of search indexing. At cutover, test the canonical domain, the www variant, HTTP, HTTPS, and several internal paths. Correct mixed-content resources at their source; do not disable TLS to hide a warning.
Verify WordPress and complete the initial setup
A login screen alone does not prove the installation is complete. Work through this list from an uncached session:
- The homepage, an internal page,
/wp-admin/, and logout all work on the canonical domain. - The browser displays a valid certificate and does not load images, fonts, or scripts over HTTP.
- Under Settings, review the site title, language, timezone, administration email, and permalink format. Save, then test an internal URL again.
- Send a controlled test email. A WordPress “sent” result does not prove delivery; confirm receipt and review the domain's mail setup.
- Remove sample content you will not use and uninstall unnecessary themes or plugins. Add extensions only from trusted, maintained sources.
- Create a named account for daily work and reserve the fully privileged account for administration.
- Enable file and database backups to a location separate from the site, define retention, and perform a test restoration.
- Review Site Health, pending updates, scheduled tasks, and private PHP/web-server logs without exposing them to the public.
Measure a baseline before adding builders, themes, and plugins. If performance degrades later, follow a controlled sequence such as these checks for speeding up a slow WordPress site instead of changing several variables at once.
Common WordPress installation errors
Safe diagnosis of common installation failures
| Symptom | Likely cause | What to check | Safe action |
|---|---|---|---|
| “Error establishing a database connection” | Incorrect database name, user, password, host, privileges, or service. | Compare all four values with the panel and confirm that the user is assigned to this database. | Correct one value at a time; do not publish wp-config.php or the password. |
| A directory listing appears | index.php is outside the document root or directory listing is enabled. | Virtual-host path, extraction directory, and configured index. | Move files to the correct destination and disable listing through supported configuration. |
| The provider's default page opens | DNS targets another destination or the domain maps to another document root. | A/AAAA records, selected virtual host, and DNS cache. | Correct the mapping; do not reinstall WordPress over another directory. |
| Internal pages return 404 | Permalink or rewrite rules are not applied. | Save Permalinks and review Apache or Nginx rules. | Use the documented configuration for your server; do not broaden global permissions. |
| HTTPS creates a redirect loop | The WordPress URL, proxy, and redirect rules disagree about the protocol. | Certificate, proxy headers, home, siteurl, and duplicate rules. | Keep one redirect source and correct how HTTPS is detected. |
| White screen or HTTP 500 | Incompatible PHP, missing extension, exhausted limit, or plugin/theme error. | Private PHP/web-server log, runtime version, and the immediately preceding change. | Undo the last change or restore; do not expose detailed errors in production. |
Rollback, security, and ongoing maintenance
If you replaced a site and validation fails, stop further changes and execute the agreed rollback. Preserve useful failure evidence, remove or isolate the incomplete installation, restore the files and database as one set, reapply server configuration, and return DNS only if it changed. Validate the former site before closing the rollback. Do not combine a new database with old files unless your recovery design explicitly calls for it.
For a new, empty installation, rollback may mean removing the files from the document root, deleting the dedicated database and user, and reversing the new virtual host or DNS records. Double-check every name and path before deletion; a shared resource is not part of this rollback.
After launch, assign owners. The provider maintains infrastructure only within the contracted scope. The site owner remains responsible for users, content, plugins, themes, and update decisions unless the service explicitly says otherwise. On a self-managed VPS, you also own the operating system, firewall, web stack, database, TLS, logs, and recovery.
- Before every material change: have a recent backup, a usable test, and a criterion for going back.
- On a regular schedule: update WordPress core, themes, and plugins after compatibility review; remove abandoned components.
- Review users and roles, login activity, file integrity, certificate expiry, and available storage.
- Test restores, not just backup creation. Keep at least one copy outside the account hosting the site.
The WordPress hardening guide makes security a layered practice. HTTPS, one strong password, or a security plugin does not replace supported software, least privilege, recoverable backups, and secure server configuration.
Frequently asked questions
Should I install WordPress at the root or in a folder?
Use the root when WordPress will be the domain's main site. Use a folder when you need a distinct section such as /blog/. Decide before installation to avoid moving files and changing URLs later.
Can I install WordPress on a VPS without a control panel?
Yes, but you first need a working web server, PHP, database, DNS, TLS, permissions, and backups. WP-CLI automates the WordPress download and configuration; it does not replace stack administration.
Why does WordPress run on an old PHP version if it is not recommended?
Compatibility is not the same as maintenance. A legacy branch may execute WordPress, but an end-of-life runtime no longer receives the expected support. Move to a recommended, compatible release after testing the site.
Should I use FTP to upload WordPress?
Do not use unencrypted FTP. The panel's File Manager, SFTP, or SSH protects the credentials and content in transit. Restrict access afterward and remove packages left under public paths.
Install, verify, and keep a way back
Choose the hosting installer to reduce complexity, the manual route to control deployment within a panel, or WP-CLI when you already operate a prepared VPS. Whichever method you use, installation is complete only after DNS, HTTPS, paths, email, backups, updates, and recovery have been verified. Record what changed and how to return to the previous state: that exit plan turns a wizard that “finished” into a site that is genuinely ready to use.
