Installing WordPress is straightforward, but a business-ready installation requires more than completing an automated wizard. The important work is preserving domain and email services, using a supported server environment, creating recoverable access and verifying the result before public launch.
Choose the installation route
| Route | Best for | What to verify |
|---|---|---|
| Host installer | Most ordinary small-business sites | The final domain, database prefix, administrator details, HTTPS and automatic-update settings |
| Manual installation | Custom environments or hosts without a reliable installer | Official download, database credentials, file permissions and server configuration |
| Developer deployment | Version-controlled or repeatable professional builds | Ownership of repository, environment settings, secrets and deployment documentation |
Before installation
- Confirm the domain and hosting are owned by the business
- Export or record existing DNS records, especially email records
- Check current WordPress and extension requirements
- Choose a named administrator account rather than a shared login
- Use a unique password and an administrator email the business controls
- Decide whether the build should remain private until launch
- Make a backup if the domain already hosts a site
Using a hosting installer
- Select the correct domain and directory. Installing into an accidental subfolder can create avoidable URL and migration work.
- Enable HTTPS if the host offers it, but confirm the certificate and redirects after installation.
- Set the administrator username, email and password deliberately. Do not accept a predictable default.
- Review optional bundled plugins and themes. Remove anything the project has not chosen.
- Complete the installation and save the hosting-level access details separately from WordPress.
Manual installation
Download WordPress only from the official project. Create a database and a dedicated database user, upload the files, visit the intended URL and follow the setup process. Manual installation is not inherently better; it is useful when the environment or deployment process requires it.
Do not expose credentials
Database passwords, salts, API keys and payment secrets should never appear in a public repository, screenshot or support ticket. Restrict access to configuration files and use encrypted transfer such as SFTP where available.
Initial configuration after installation
- Set site language, timezone and date format
- Review permalink structure before publishing
- Confirm the site address and WordPress address
- Delete sample posts, pages and comments
- Remove unused themes and plugins after keeping an appropriate fallback theme
- Create separate user accounts with the lowest practical role
- Confirm outgoing email delivery
- Keep search-engine visibility disabled until launch if the site is incomplete
Verify the installation
| Check | Pass condition |
|---|---|
| Front end | The intended domain loads over HTTPS without mixed-content warnings |
| Administration | The named administrator can log in and recover the password |
| Updates | Core, theme and plugin update screens load without filesystem errors |
| A password-reset or test message reaches the controlled mailbox | |
| Backup | Files and database are included in a backup stored outside the live site |
| Privacy | The unfinished site is not accidentally open to indexing or public registration |
Rollback plan
If installation replaces an existing site, retain a complete pre-change backup and the former DNS values. Define who can restore the previous site and how long that restore is expected to take before changing live traffic.
Practical next step
Install on a private or staging location first, record every account and setting, then run the verification table before connecting the public domain.
Common installation mistakes
- Installing at a temporary URL and later performing an uncontrolled search-and-replace.
- Changing nameservers without preserving email and verification records.
- Using the developer’s private email as the only administrator and recovery address.
- Accepting bundled plugins without reviewing their purpose and data access.
- Publishing sample pages, default privacy text or an unfinished site.
- Assuming the host backup includes both the database and all uploaded files.
When an existing domain is involved
Separate building from traffic switching. A new WordPress installation can be prepared on staging or a protected technical address while the existing site and email continue to operate. Only change DNS after the new site, redirects, certificates and rollback route have been tested. Record the former DNS values and avoid changing unrelated records during the launch.
Sources and date checked
This guide was checked on 21 July 2026. WordPress, hosting environments and extensions change, so recheck the relevant official documentation before making a major change.
Keep the decision under your control
Retain the relevant accounts, source material, supplier terms and recovery information. Recheck changing prices, interfaces and rules before acting.