Running WordPress on your own VPS gives you speed and control, but it also means nobody else is checking the boring details for you. This is the list I go through before a site on CloudPanel, Nginx and Cloudflare goes live. None of it is clever — it is just the set of things that cause problems when they are forgotten.
SSL and Cloudflare
- Use a real certificate on the server. Issue a Let’s Encrypt certificate in CloudPanel, or install a Cloudflare origin certificate, so traffic is encrypted all the way to your VPS.
- Set Cloudflare’s SSL mode to Full (strict). “Flexible” sends traffic to your server over plain HTTP and is a common cause of redirect loops with WordPress.
- Check that WordPress sees the real visitor IP. Behind Cloudflare, every request appears to come from Cloudflare unless Nginx is told to trust its IP ranges and read the visitor’s address from the forwarded header. Without this, security plugins, rate limits and logs all see the wrong IP.
Caching
- Decide which layer caches what. Between Varnish, Cloudflare and any WordPress cache plugin, it is easy to stack three caches that disagree. Pick one layer for full-page caching and make sure the others know how to purge.
- Never cache logged-in or personal pages. Admin screens, carts, checkouts, account pages and anything that sets a session cookie must bypass the page cache.
- Test a purge. Edit a page, then load it in a private window. If you still see the old version, find out why before launch, not after.
WordPress settings
- Untick “Discourage search engines” under Settings → Reading if it was ticked during development.
- Turn debugging off.
WP_DEBUGandWP_DEBUG_DISPLAYshould be false on a live site so errors are logged, not shown to visitors. - Disable the file editor. Adding
define( 'DISALLOW_FILE_EDIT', true );towp-config.phpremoves the theme and plugin editors from the dashboard. - Set permalinks before anything is indexed, so URLs don’t change later.
- Check the sitemap and robots.txt. Open both in a browser and confirm they list the pages you expect.
Cron
WordPress’s built-in cron only runs when someone visits the site. On a quiet site scheduled posts can be late; on a cached site, requests may never reach PHP at all. I disable it with define( 'DISABLE_WP_CRON', true ); and add a real cron job for the site user in CloudPanel that runs wp cron event run --due-now every few minutes.
- Send through a proper mail service. Mail sent straight from a VPS is often rejected or marked as spam. Use an SMTP plugin with a transactional mail provider or your domain’s mail host.
- Set SPF, DKIM and DMARC DNS records for the sending domain.
- Test the contact form end to end, including a reply, and check the spam folder.
Backups and recovery
- Back up files and the database off the server. CloudPanel can send backups to remote storage; a backup that lives on the same VPS does not protect you from losing that VPS.
- Restore once. A backup you have never restored is a guess. Restore to a staging site at least once so you know the steps.
Security basics
- Keep each site under its own system user, which CloudPanel does by default.
- Use SSH keys rather than passwords, and keep the CloudPanel admin port restricted.
- Remove plugins and themes you are not using instead of just deactivating them.
- Turn on two-factor authentication for every administrator account.
After launch
- Add the site to Google Search Console and submit the sitemap.
- Set up uptime monitoring so you hear about downtime before your visitors tell you.
- Look at the server error log after the first day of real traffic.
It is a long list, but most items take a minute each. Going through it once before launch is far cheaper than finding each problem one at a time on a live site.