A fresh WordPress installation is not ready for public traffic until you verify Apache is serving the right site, finish the browser setup, update Ubuntu and WordPress, secure administrator access, enable HTTPS, configure permanent URLs, review permissions, and prove that a backup can be restored.
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
Work through the sequence below in order. It separates one-time decisions—such as your domain and permalink format—from repeatable maintenance tasks, and ends with an acceptance test you can use before announcing the site.
As an Amazon Associate I earn from qualifying purchases.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Use this order for a new Ubuntu WordPress site
The order matters because later settings depend on earlier ones. For example, changing URLs before Apache rewrite support is working can produce broken links, and installing many plugins before applying updates makes troubleshooting harder. Keep a terminal session, your domain registrar or DNS controls, and the WordPress Dashboard available.
| Stage | What to verify | Evidence that it is complete |
|---|---|---|
| 1. Web server | Apache virtual host, document root, rewrite module, and reload | The intended domain displays the intended WordPress files, not Apache’s default page |
| 2. Initial setup | Site title, final hostname, email, and a separate administrator identity | You can sign in with WordPress credentials that are not reused anywhere else |
| 3. Updates | Supported Ubuntu security updates and current WordPress core, plugins, and themes | Dashboard update notices are cleared or deliberately deferred |
| 4. Protection | Strong authentication, HTTPS, URL consistency, ownership, and permissions | Login and tested pages use HTTPS and no unnecessary account or file access remains |
| 5. Recovery | Complete backup and a documented restore test | You have both database and file copies and have successfully recovered a test copy |
| 6. Acceptance | Front end, administration, uploads, permalinks, forms, and redirects | A short repeatable test passes before public promotion |
1. Verify Apache and the site mapping
Ubuntu’s official WordPress tutorial uses the upstream release from WordPress.org rather than the WordPress package in the Ubuntu Archive. Whichever installation method you used, first prove that Apache is serving the correct files for the correct hostname. A successful browser page alone is not enough: a default virtual host can display a page while your intended site remains unmapped.
#1 Best Overall
Confirm the document root and virtual host
Inspect the enabled Apache site configuration and check that its DocumentRoot points to the directory containing wp-admin, wp-content, and wp-includes. The ServerName and any intended aliases must match the hostname visitors will use. If Apache’s default site is still enabled and catches the request first, disable it or replace it with your site configuration.
sudo a2ensite your-site.conf
sudo a2dissite 000-default.conf
sudo a2enmod rewrite
sudo systemctl reload apache2Use the actual configuration filename on your server; do not run a command that disables a site you still need. A reload applies configuration changes without the full interruption of a stop-and-start cycle. If Apache reports a syntax error, run its configuration test, correct the reported file, and reload only after the test succeeds.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Check the request that matters
Browse to the final hostname, including the exact scheme you plan to publish. Confirm that the page title, logo or theme, and any existing content belong to this installation. Also request a nonexistent path. Before permalinks are configured, a controlled “not found” response is expected; an Apache default page, another project, or a directory listing indicates a mapping or permission problem.
2. Finish the browser installation with separate credentials
Open the WordPress installation screen at the mapped hostname and enter the final site title, public domain, administrative email address, and a new administrator account. WordPress credentials must not be reused for MySQL, Ubuntu, SSH, or any other service. The Ubuntu documentation treats these as separate identities because compromise of one layer should not automatically grant access to the others.
Choose the administrator identity deliberately
- Use a unique account name rather than an obvious name such as “admin” or the site name.
- Generate a long, unique password and store it in a password manager.
- Use an email address you actively monitor; it is needed for recovery and security notices.
- Create ordinary author or editor accounts for publishing work instead of sharing the administrator account.
After the first login, visit the profile screen and verify the displayed name, email address, timezone, and visual preferences. Keep the administrator account for configuration and emergency work. Separating publishing identities gives you a clearer audit trail and limits the damage if an editor’s password is exposed.
3. Update Ubuntu and WordPress before adding extensions
Updates are part of the initial installation, not a task to postpone until after customization. Ubuntu documents security updates for supported releases and provides automatic security updates through unattended-upgrades. WordPress also warns that older versions are more exposed because vulnerability details become public after fixes are available.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchApply operating-system updates
sudo apt update
sudo apt full-upgradeReview packages that will change, especially PHP, Apache, database, and kernel components. On a production host, schedule a maintenance window if a reboot may be required, and keep a console or out-of-band recovery path available. Confirm the Ubuntu release remains within its supported security-maintenance period. Do not remove packages simply to make the update list appear empty.
Apply WordPress updates in the Dashboard
Go to Dashboard → Updates and update WordPress core, installed plugins, and themes. Read the change notes for major updates, take a backup before a substantial change, and update one logical group at a time if the site already contains custom code. Visit the front end and administration screens after each group. If a plugin is unused, remove it rather than leaving inactive code in the web root.
Decide how future updates will run
| Approach | Strength | Risk or requirement |
|---|---|---|
| Automatic security updates | Rapid response to security fixes with little manual work | You need recent backups, monitoring, and a rollback plan for incompatibilities |
| Manual, scheduled updates | Change control and a defined test window | Someone must monitor advisories and apply fixes promptly |
Whichever approach you choose, document who receives update notices, where logs are checked, and how a failed update is reversed.
4. Harden administrator access
Authentication is the next priority because a compromised administrator can change content, install code, and alter recovery settings. WordPress hardening guidance recommends avoiding easily guessed administrator usernames and enabling two-step authentication.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsUse strong, unique sign-in protection
- Keep the administrator password unique to this site and store it in a reputable password manager.
- Enable two-step authentication for administrator accounts using a method your team can recover if a device is lost.
- Use separate accounts for administration, editing, and automated integrations.
- Remove old users and review each account’s role; do not leave former contractors with active access.
- Protect the email account used for WordPress recovery with its own strong password and two-step authentication.
Do not rely on an obscure login URL as your primary defense. It can reduce noise but does not replace strong credentials, updates, least-privilege roles, and monitoring. Record recovery codes offline where your organization can retrieve them without placing them beside the server’s credentials.
5. Enable HTTPS before public use
The WordPress Hosting Handbook strongly recommends HTTPS to help protect both WordPress logins and site visitors. Install a valid TLS certificate for the public hostname at the web-server layer, configure Apache to serve the certificate, and redirect ordinary HTTP requests to HTTPS according to your certificate provider’s instructions.
Change WordPress’s URL settings after TLS works
In Settings → General, check WordPress Address (URL) and Site Address (URL). For a normal single-site installation, both should use the final HTTPS domain consistently. They can differ in special deployments, such as when core files are kept in a separate directory, but do not create that split casually.
Save the settings only after the HTTPS virtual host responds correctly. Then test the home page, several internal pages, the login screen, media URLs, and a logout/login cycle. A browser warning about mixed content means some page still requests an HTTP asset; identify and correct that URL rather than ignoring the warning. If changing the fields locks you out, restore the previous values from a backup or use the documented configuration method for your deployment, then fix the underlying redirect or virtual-host issue.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →6. Select a stable permalink structure
Permalinks are the permanent URLs assigned to posts and pages. WordPress’s documentation emphasizes that a post URL should remain permanent, so choose a human-readable format before publishing links widely. Go to Settings → Permalinks, select the structure that fits your content, and click Save Changes even if the desired option was already selected.
Make rewrite support and file rules agree
Pretty permalinks require Apache’s rewrite module and rules in the site’s .htaccess file when that method is used. If WordPress cannot write the file, it displays the rules you need to copy manually. Place those rules in the correct document root, preserve the file’s ownership and permissions, and save the permalink settings again.
Test a published or draft page with a clean, human-readable path, then test a deliberately invalid path. A 404 for the invalid path is normal; a 404 for every valid page usually means the virtual host, rewrite module, AllowOverride policy, or .htaccess location is wrong. Do not change permalink formats after distributing links unless you have a redirect and migration plan.
7. Check both URL fields before publishing
WordPress Address (URL) identifies where the WordPress core files live. Site Address (URL) is the address visitors use. In a conventional single-site setup they are identical, including scheme, hostname, and (if applicable) port. A mismatch can create redirect loops, broken media links, or an administration screen that points to the wrong host.
Recommended Free Tools
Rank #4
Write down the intended canonical URL before publishing and compare it with the two fields, the Apache virtual host, certificate names, and any reverse-proxy configuration. Back up before changing a live URL. URL changes can require updated rewrite rules and follow-up checks of serialized settings, feeds, media, and redirects; treat them as a migration rather than a cosmetic edit.
8. Review ownership and permissions
File access must let the web server read WordPress and write only where the site requires it. It must not give every local user unrestricted control of the installation. The Ubuntu tutorial warns that making all files owned by www-data can be insecure on a multi-site server and recommends per-site users and restrictive wp-config.php permissions in that situation.
Use isolation appropriate to the host
| Server model | Practical ownership approach | Why it matters |
|---|---|---|
| One site on a dedicated host | A simple web-server user model may be workable if write access is tightly limited | Fewer tenants reduce cross-site exposure, but configuration still needs review |
| Several independent sites | Use a separate Unix user and suitable PHP/Apache isolation for each site | A compromised site should not be able to modify neighboring sites |
Keep wp-config.php readable by the process that needs it and inaccessible to unrelated users. Give upload directories the write access required for media, but do not make the entire codebase universally writable. Check that .htaccess can be updated when you intentionally save permalink settings; if it cannot, add rules through a controlled administrative process instead of broadly opening permissions.
After any ownership change, verify that the Dashboard can update only when you expect it to, that uploads succeed, and that Apache cannot serve configuration files as downloads.
9. Create a complete backup and prove restoration
A WordPress backup is not just a database export. Preserve the database plus WordPress core files, wp-content (including uploads, themes, and plugins), configuration, and any server-level rewrite or virtual-host files needed to recreate the site. WordPress hardening guidance recommends regular whole-installation snapshots, trusted storage, and testing that a backup can actually be restored.
Define the backup set
- Database: posts, pages, users, settings, comments, and plugin data.
- Files: uploads, active and inactive themes, plugins, WordPress core, and
wp-config.php. - Infrastructure notes: Ubuntu release, PHP and database versions, Apache site configuration, TLS renewal details, DNS values, and scheduled jobs.
- Credentials and keys: store separately in a protected password or secrets manager, not in an unencrypted archive.
Test a restore, not just a download
Restore the archive to an isolated hostname or server, import the database, place the files in the matching document root, and adjust the test URL without exposing the copy to public search or login traffic. Open the home page, sign in, view an uploaded image, open a pretty permalink, and check that forms or comments behave as expected. Record the date, software versions, backup location, and the person who confirmed the restore. Repeat at an interval appropriate to how often the site changes.
10. Run a small acceptance test
Perform this test from a normal browser session and, where relevant, a private window or a second device. It catches configuration errors that a successful installation screen cannot reveal.
- Open the public hostname and confirm the expected site appears, not Apache’s default page or another virtual host.
- Confirm the address bar stays on HTTPS and that the browser reports a valid certificate.
- Log in with the administrator account, then log out and verify that protected screens require authentication again.
- Create a draft, preview it, and confirm that the editor can save without unexpected permission errors.
- Upload an image, insert it into a draft, publish or preview the page, and open the image URL.
- Open a page and post using the selected permalink format. Test an invalid path to confirm a controlled 404 page.
- Submit the contact form or comment workflow if the site enables one, and verify delivery, moderation, and spam controls.
- Inspect several pages for mixed-content warnings, broken images, redirect loops, and links pointing to an old hostname.
- Check the Dashboard for pending core, plugin, and theme updates and decide whether each is installed, scheduled, or intentionally deferred.
- Verify that the latest backup archive exists and that the restore procedure and last successful test are documented.
Common failures and the fastest diagnostic path
The domain shows the wrong site
Check DNS resolution first, then the Apache ServerName, enabled-site list, and document root. Disable or replace the default site only after confirming it is not needed for another hostname. Reload Apache and retest using the exact public host header.
Free tools Windows power users keep installed
One-click scans. No signup required.
Pretty links return 404
Confirm rewrite is enabled, the virtual host permits the required overrides, and .htaccess is in the document root with appropriate permissions. Save the permalink settings again. If only one page fails, inspect its slug and publication status; if every page fails, focus on Apache routing.
HTTPS redirects loop or the dashboard becomes inaccessible
Compare the TLS virtual host, proxy or load-balancer scheme, and both WordPress URL fields. A proxy that terminates TLS must pass the original scheme correctly. Temporarily restore the last known-good URL values from your backup, correct the layer that is disagreeing, and then retest in a private browser window.
WordPress cannot install updates or upload media
Review ownership and write permissions for the specific directories involved instead of making the whole installation writable. On a multi-site host, verify that the site’s Unix user and PHP process are isolated from neighboring sites. Check available disk space and PHP limits only after filesystem access is correct.
The restore opens a blank or broken site
Confirm that the database and files came from the same capture, the PHP and database versions are compatible, and the test URL was changed consistently. Recheck the document root, wp-config.php database settings, rewrite rules, and file permissions. A restore that works only on the original server is not a dependable backup.
When the site is ready for public traffic
Publish only when the intended virtual host serves the intended files, HTTPS is valid, both URL fields are correct, permalinks work, administrator access is protected with unique credentials and two-step authentication, permissions match the server model, updates are current or deliberately scheduled, and a complete restore has succeeded. Keep the acceptance-test list and restore record with the site’s operational documentation so the same checks can be repeated after migrations, URL changes, or major updates.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
